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Chapter  One 
Introduction 

1.1.  Purpose  of  an  Architecture  Simulator 

As  computer  chips  have  grown  in  complexity,  the  need  for  tools  to 
aid  the  engineer  in  designing  and  testing  a  proposed  architecture  has 
increased  greatly.  Many  of  these  tools  are  available  as  computer 
programs,  some  of  which  are  silicon  compilers,  RTL  (Register  Transfer 
Language),  or  ISP  (Instruction  Set  Processor).  A  silicon  compiler  deals 
with  the  actual  hardware  mask  generation  and  can  be  quite  difficult  to  use. 
ISP  defines  each  opcode  as  an  instruction  to  be  executed,  and  thus  is  a  one 
to  one  replacement  of  the  assembly  code  to  a  "high  level  language".  RTL, 
which  is  classified  as  a  CHDL  (Computer  Hardware  Description 
Language),  lies  between  silicon  compilers  and  ISP  in  terms  of  the  level  of 
abstraction  it  deals  with.  This  thesis  will  concentrate  on  examining  and 
using  an  RTL. 

Using  a  software  simulator  can  greatly  reduce  the  cost  of  designing 
a  new  microprocessor  by  avoiding  physical  construction.  This  physical 
construction  is  usually  more  error-prone  and  labor  intensive  than  a 


software  system  due  to  the  need  to  actually  build  the  circuit  under 
consideration.  Great  care  must  be  taken  to  ensure  that  wires  are  hooked  up 
correctly  and  that  the  individual  chips  are  working  properly.  Also,  as 
complexity  increases,  the  length  and  type  of  connections  becomes  critical 
and  may  cause  problems  which  are  not  readily  apparent.  Some  of  these 
problems  can  be  ignored  during  the  simulation  phase  without  serious 
consequence;  they  can  be  dealt  with  during  the  production  of  a  prototype. 
Since  the  project  can  be  simulated  on  an  existing  computer,  building  a 
prototype  is  not  necessary  until  later  in  the  design  phase. 

In  the  past  three  years,  only  brief  mention  is  made  of  CHDLs  in  the 
literature,  partially  due  to  manufacturers  developing  their  own  CHDL  and 
retaining  it  as  a  trade  secret  [50].  In  light  of  this,  it  may  be  quite  difficult 
for  a  single  CHDL  to  become  a  standard  for  computer  architecture  design, 
implementation,  and  comparison.  Some  of  the  current  CHDL 
implementations  are  relatively  old  and  are  more  difficult  to  port  over  to  a 
newer  and  faster  computer.  In  implementing  a  new  CHDL,  it  is  desirable 
to  promote  porting  to  other  computers  and  to  promote  standardization  of 
hardware  representation  at  the  register  transfer  language  level.  It  is 
desirable  to  provide  a  complete  set  of  primitives  with  which  a  designer  can 
define  a  circuit. 


1 .2.  Instruction  Set  Processor 

ISP  translates  each  opcode  of  the  test  architecture  to  an  expression 
in  a  high  level  language  where  the  instruction  execution  is  often 
implemented  as  a  large  case  structure  [67].  This  level  of  translation  does 
not  lend  itself  well  to  actual  circuitry  generation,  but  is  useful  in  designing 
an  instruction  set  for  the  microprocessor  to  execute  and  for  simulating  that 
execution.  After  the  instruction  set  has  been  generated  and  tested,  it  can  be 
converted  to  an  RTL  for  further  testing.  The  RTL  provides  a  circuit  level 
definition  of  the  microprocessor. 

1.3.  Machine  Cycle  Simulator 

The  machine  cycle  simulator,  a  technique  especially  useful  in 
microprocessor  design,  is  somewhat  related  to  the  ISP.  In  addition  to  the 
capabilities  of  the  ISP,  the  machine  cycle  simulator  traces  the  events  at  each 
cycle,  thus  providing  timing  information  not  available  via  an  ISP.  This 
type  of  simulator  is  quite  close  to  an  RTL  simulator  in  the  type  of 
information  provided  by  the  simulation  run.  However,  the  machine  cycle 
simulator  specification  is  more  difficult  to  convert  to  an  actual  circuit  than 
the  RTL  specification  because  it  still  does  not  represent  the  hardware  in 
detail. 


1 .4.  Register  Transfer  Language 

RTL  machine  simulation  is  the  process  whereby  a  program  written 
in  the  assembly  code  of  the  machine  to  be  simulated  is  read  and  executed  by 
a  different  machine.  The  result  is  the  same  as  executing  the  code  on  the 
architecture  being  simulated  [67].  Other  forms  of  RTL  simulation  employ 
a  machine  which  has  characteristics  that  are  not  physically  present.  This 
virtual  machine  may  have  more  memory  or  a  different  instruction  set, 
among  other  characteristics. 

An  RTL  defines  the  instruction  set  of  a  microprocessor  for 
simulation  in  terms  of  a  small  set  of  register  transfer  statements.  If  the 
RTL  statements  are  carefully  chosen,  they  will  remain  unchanged  as 
instruction  sets  are  defined  for  various  microprocessors.  An  RTL  is  not 
limited  to  microprocessors,  but  can  also  be  used  for  almost  any  other  piece 
of  digital  electronic  hardware.  This  extends  its  usefulness  beyond 
computer  architecture  to  the  electrical  engineering  field. 

The  basic  composition  of  an  RTL  for  a  microprocessor  is  as 
follows.  The  microprocessor  is  defined  in  terms  of  a  set  of  register 
transfers  which  carry  out  the  intended  function  in  the  same  way  the  actual 
microprocessor  would  perform  it.  These  register  transfers  are  a  mapping 
of  the  data  flow  through  the  microprocessor.  A  translator  then  reads  these 
instructions  to  simulate  the  proposed  architecture.  The  actual  circuitry  and 


the  register  transfer  code  generate  exactly  the  same  final  output.  In 
addition  the  register  transfer  execution  will  typically  produce  statistics 
about  the  actual  simulation,  such  as  execution  cycles  required,  memory 
accesses,  and  other  related  information.  This  extra  output  is  invaluable 
when  the  designer  desires  to  view  the  internal  states  of  a  microprocessor. 
With  the  RTL  model,  this  is  easily  accomplished;  however,  with  the 
hardware  prototype,  this  can  be  difficult  or  impossible  due  to  the  need  to 
attach  additional  hardware  to  monitor  the  various  signals. 

A  model  of  a  real  (or  proposed)  microprocessor  can  be  defined 
using  an  RTL.  Tests  may  be  run  comparing  different  implementations  of 
the  same  languages,  or  of  various  languages.  Studies  of  this  sort  could  then 
be  applied  to  various  compilers  running  on  this  microprocessor. 
Comparisons  could  be  made  on  execution  efficiency  of  the  compiler.  In 
this  way,  a  compiler  writer  could  ascertain  the  statements  for  which  the 
compiler  has  difficulty  generating  efficient  code,  and  possibly  deal  with 
these  inefficiencies  at  the  RTL  level.  These  inefficiencies  can  be  dealt  with 
by  changing  the  register  transfer  sequences  within  the  microprocessor  to 
make  it  more  closely  conform  to  the  way  compilers  tend  to  generate  code. 
More  importantly,  the  architecture  could  be  changed  with  no  hardware 
modifications. 


1.5.  Silicon  Compilers 

In  this  study,  an  RTL  compiler  written  in  Pascal  is  presented  that 
will  read  the  RTL  specification  and  produce  a  Pascal  program.  This 
resulting  program  will  then  simulate  the  target  architecture  and  produce 
output  at  each  cycle  of  the  simulation.  There  exists  an  RTL  interpreter 
with  the  same  input  specification.  The  compiler  written  in  this  study 
generates  code  which  executes  approximately  an  order  of  magnitude  faster 
than  the  current  simulator.  The  present  interpreter  is  used  in  the 
classroom  at  Kansas  State  University,  and  is  too  slow  for  use  in  large 
projects. 

Silicon  compilers  can  be  used  to  produce  a  mask  used  in  the  actual 
production  of  the  individual  chips  (microprocessor,  controllers,  and  other 
specialized  chips),  and  thus  find  their  way  into  the  CAD/CAM  category. 
However,  the  silicon  compiler  is  not  very  well  suited  for  the  testing  of  the 
design  functionality  of  microprocessor  chips.  Also,  the  silicon  compilers 
available  today  are  quite  inefficient  both  in  terms  of  ease  of  use  and 
production  efficiency  (in  terms  of  physical  layout  of  the  gates  on  the  actual 
chip  surface)  of  the  final  chip  specification  [47].  An  RTL  is  needed  in  the 
early  stages  of  development  to  ease  the  design  of  the  chip  that  actually 
performs  the  desired  function. 


Whereas  a  silicon  compiler  is  concerned  with  the  actual  connection 
and  layout  of  the  gates  in  a  chip,  an  RTL  avoids  the  gate  level.  Since  the 
RTL  is  a  higher  level  of  abstraction,  a  correct  design  is  easier  to  build  with 
an  RTL  than  with  a  silicon  compiler.  Occasionally  gates  must  be  simulated 
in  a  microprocessor  description,  for  example  by  saving  certain  internal 
flags  or  operation  results  in  flip-flops  or  to  describe  a  specific  interface 
from  memory  to  an  ALU  (Arithmetic  Logic  Unit).  After  the  RTL 
specification  has  been  designed  and  rigorously  tested,  the  design  may  then 
be  converted  to  a  language  suitable  for  a  silicon  compiler  which  will 
produce  the  actual  layout  diagrams  for  production. 

1.6.  Definitions 

In  simulation  languages,  just  as  in  programming  languages,  the 
terms  "procedural",  "nonprocedural",  "serial",  "parallel",  and 
"concurrent"  are  very  common.  These  terms  are  discussed  below. 

In  a  programming  language,  strict  timing  constraints  seldom  need 
to  be  enforced.  In  contrast,  for  a  simulation  language,  timing  is  critical  to 
the  analysis  of  a  design.  Many  times  the  designer  must  know  the  exact 
cycle  in  which  a  particular  event  occurs  so  that  the  information  can  be 
captured  and  analyzed  properly.  Each  simulated  unit  has  a  "simulation 
time"  associated  with  it.  The  simulation  time  (or  clock  cycle)  carries  with 


it  the  values  of  different  components  (registers,  gates,  flip-flops,  etc.) 
corresponding  to  that  particular  simulation  time. 

Depending  on  the  sequencing  structure  and  control  structure  of  the 
underlying  language,  a  language  can  be  classified  as  procedural  or 
nonprocedural.  A  set  of  statements  is  procedural  if  the  statements  are 
executed  in  the  same  order  as  they  are  specified.  This  is  typical  of  most 
programming  languages  in  use  today.  In  a  nonprocedural  language,  the 
order  of  execution  is  not  necessarily  the  same  order  as  the  statements  are 
specified. 

The  terms  parallel  and  serial  are  commonly  used  in  conventional 
programming  languages  as  well  as  CHDLs.  In  CHDLs  the  term  parallel 
means  that  the  actions  specified  are  to  be  executed  simultaneously  or  in  the 
same  simulation  time.  The  term  serial  means  one  after  the  other.  Two 
sequencing  mechanisms  exist  in  programming  languages.  Procedural 
means  that  the  statements  are  executed  in  the  same  order  as  specified.  The 
term  nonprocedural  refers  to  the  absence  of  a  sequencing  mechanism. 
Concurrent  means  that  two  (or  more)  processes  can  be  executing  at  the 
same  time,  and  that  any  communication  between  the  processes  must  be 
explicitly  specified.  The  term  concurrent  is  not  synonymous  with  the  term 
parallel.  If  statements  are  executed  in  parallel,  all  are  executed  in  the  same 
simulation  time.    No  concept  of  simulation  time  exists  in  concurrent 


operations.  Parallel  blocks  are  synchronous,  while  concurrent  blocks  are 
asynchronous.  In  some  CHDLs,  a  condition  is  associated  with  each 
statement  or  statement  body.  In  these  languages,  all  statement  bodies  with  a 
true  condition  are  executed  in  a  nonprocedural  and  parallel  fashion. 


Chapter  Two 
Review  of  Existing  CHDLs 

2.1.  Representative  CHDLs 

A  number  of  CHDLs  have  been  designed  to  describe  different  levels 
of  hardware.  Each  has  been  developed  for  a  specific  use  at  a  certain  level 
of  abstraction.  Some  CHDLs  lie  on  the  border  of  two  abstraction  levels 
and  use  features  from  both  levels,  but  may  not  be  able  to  fully  implement 
both  levels  of  abstraction.  The  following  section  presents  a  brief  review  of 
several  existing  CHDLs.  The  levels  of  abstraction  are  described  later  in 
this  chapter. 

2.1.1.  CDL 

CDL  (Computer  Design  Language)  is  an  Algol-like  hardware 
description  language  developed  by  Yaohan  Chu  at  the  University  of 
Maryland.  CDL  describes  the  structural  and  functional  parts  of  a  digital 
system  [50].  The  structural  components  (memory,  registers,  clocks,  and 
switches)  are  declared  explicitly  at  the  beginning  of  the  description.  The 
functional  behavior  of  each  element  is  described  using  operators.    The 
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system  can  be  described  at  only  one  level  of  abstraction.  There  is  no 
subroutine  facility  in  CDL,  thus  making  it  unsuitable  for  modular 
description  of  a  system.  However,  its  simple  structure  and  portability 
(implemented  in  Fortran)  have  made  CDL  a  popular  language.  The 
language  makes  use  of  Fortran's  operators  as  well  as  user  defined 
operators.  CDL  can  be  used  to  describe  complex  digital  systems.  CDL  was 
implemented  in  two  parts:  a  translator  and  a  simulator.  The  translator 
performs  a  syntax  check  of  the  description  and  translates  it  into  a  set  of 
tables  and  a  polish  string  program.  The  simulator  executes  the  output  of 
the  translator  and  can  accept  simulation  parameters  through  the 
commands:  LOAD,  OUTPUT,  SWITCH,  RESET,  and  SIMULATE.  CDL 
does  have  some  drawbacks.  It  does  not  easily  lend  itself  to  hardware 
generation.  Also,  because  of  the  nonmodular  description  feature  of  CDL 
and  the  difficulty  in  using  the  polish  string  output  of  the  translator  to 
generate  logic  diagram  level,  it  is  unsuitable  for  a  Computer- Aided  Design 
And  Test  (CAD AT)  system. 

2.1.2.  ISP 

ISP  (Instruction  Set  Processor),  as  designed  by  Bell  and  Newell, 
was  initially  intended  to  be  used  only  for  documentation  purposes  [10,  24]. 
Now,  however,  it  is  being  used  for  design  automation,  software 
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generation,  program  verification,  and  architecture  evaluation.  ISPS 
(Instruction  Set  Processor  Specifications)  is  a  computer  language  based  on 
ISP  for  which  a  compiler  and  simulator  have  been  produced.  ISPS  is  a 
procedural  language  to  describe  instruction  sets.  Since  it  simulates  an 
architecture  at  the  instruction  set  level,  ISPS  does  not  provide  any  data 
concerning  concurrency,  timing,  or  interconnection  of  processors.  A  user 
can  arbitrarily  stop,  start,  and  count  events  during  the  execution  of  the 
simulator,  or  examine  and  modify  the  contents  of  registers.  By  comparing 
the  results  of  the  simulation  with  expected  results,  the  user  can  detect 
errors  in  the  design  of  the  system.  ISPS  is  best  suited  to  provide 
performance  information  for  a  hypothetical  architecture. 

2.1.3.  AHPL 

AHPL  (A  Hardware  Programming  Language)  is  a  procedural 
language  developed  by  F.  J.  Hill  at  the  University  of  Arizona.  Like  CDL, 
AHPL  is  popular  and  well  documented  [37].  AHPL  has  applications  in 
three  areas:  documentation,  design  verification  and  automatic  design.  It  is 
supported  by  a  simulator  which  provides  design  verification.  A  hardware 
compiler  provides  automatic  design  by  translating  AHPL  descriptions  to 
wiring  lists  specifying  the  interconnections  of  gates.  The  principle 
weakness  in  AHPL  is  its  difficulty  to  express  parallelism. 
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2.1.4.  DDL 

DDL  (Digital  system  Design  Language)  is  a  complex  and  powerful 
block  oriented  nonprocedural  language  [25].  It  is  based  on  finite  state 
machines  and  is  designed  to  describe  digital  systems  at  the  boolean 
equation,  register  transfer  and  algorithmic  levels.  Many  of  its  features  are 
similar  to  CDL,  but  in  addition  it  allows  the  design  to  be  specified  in  a 
block  oriented  fashion.  This  allows  the  designer  to  construct  a  portion  of 
the  system,  test  it,  and  use  that  block  as  a  module  which  is  already 
debugged.  These  blocks  are  expanded  to  their  boolean  equation 
equivalents  for  actual  simulation  [50].  By  incorporating  this  capability, 
DDL  has  lost  some  of  its  flexibility  as  a  simulator.  DDL  is  well  supported 
by  software.  A  translator  and  simulator  were  implemented  in  IFTRAN  on 
a  Harris  6024  machine.  This  translator  converts  DDL  descriptions  to  a  set 
of  boolean  equations  and  register  transfer  expressions  which  can  be  used 
for  hardware  compilation.  DDL  is  so  well  documented  that  it  is  used  as  an 
instructional  example  in  two  text  books  [15,  23]. 

2.1.5.  ADLIB 

ADLIB  (A  Design  Language  for  Indicating  Behavior)  is  a  part  of 
the  SABLE  (Structure  And  Behavior  Linking  Environment)  simulation 
and  design  automation  system  developed  at  Stanford  University  [64]. 
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ADLIB  was  developed  to  describe  the  computer  component  types.  The 
interconnection  of  the  component  types  is  specified  in  a  separate  language, 
SDL  (Structure  Design  Language).  This  ADLIB/SABLE/SDL  system  is 
designed  to  describe  digital  systems  at  different  levels  of  abstraction.  This 
is  an  important  feature  which  allows  the  designer  to  describe  a  subsystem, 
and  use  that  description  in  several  other  places  without  having  to  replicate 
the  description.  This  saves  time  by  reducing  the  amount  of  work  necessary 
in  the  description,  as  well  as  reducing  the  number  of  potential  design 
errors.  The  multi-level  description  and  simulation  approach  also  aids  in 
validating  a  lower  level  design.  For  example,  a  system  can  be  described  at 
the  behavior  level  and  also  at  the  structure  level.  Both  simulation  results 
can  then  be  compared  to  assure  the  designer  of  similar  descriptions. 

ADLIB  is  a  superset  of  Pascal  and  thus  is  strongly  typed  like  Pascal. 
It  extends  Pascal  with  constructs  to  specify  synchronous  and  asynchronous 
timing,  extendable  data  types,  subprocesses  and  intercomponent  signaling. 
It  is  well  supported  in  software. 

The  strength  of  ADLIB  is  also  its  weakness.  ADLIB  works  well  at 
the  behavior  level,  but  does  not  work  well  at  the  structure  level.  Structure 
level  simulation  is  an  important  aspect  of  CHDLs  which  are  used  to  design 
a  circuit  for  the  specification. 
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2.1.6.  DTMS 

DTMS  (Descriptive  Techniques  for  Modules  and  Systems)  was 
developed  at  Kansas  State  University  to  better  describe  digital  systems 
consisting  of  the  interconnection  of  complex  MSI  (Medium  Scale 
Integration)  and  LSI  (Large  Scale  Integration)  modules  [55].  Descriptions 
in  DTMS  reflect  the  modular  hardware  of  modern  digital  systems.  Module 
functions  are  described  at  a  high  behavior  level,  and  their  interconnections 
are  specified  at  the  structural  level.  These  modules  communicate  to  each 
other  through  busses.  DTMS  allows  both  procedural  and  nonprocedural 
constructs  to  be  expressed  through  PROCESS  and  NONPROCESS 
sections.  It  is  not  implemented  in  software;  instead  it  is  intended  as  a 
documentation  tool. 

2.1.7.  CONLAN 

The  development  of  CONLAN  (CONsensus  LANguage)  goes  back 
to  the  first  Symposium  on  Hardware  Descriptions  Languages  (HDL)  at 
Rutgers  University  [43, 44,  45].  The  lack  of  an  industry  acceptance  of  the 
dozens  of  HDLs  then  in  existence  prompted  a  team  of  people  from  the 
United  States  and  Europe  to  develop  a  language  in  which  HDLs  could  be 
standardized.  There  are  several  reasons  why  acceptance  of  existing  HDLs 
is  so  low: 
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1.  None  of  the  languages  alone  is  sufficient  to  describe  all  aspects  of 
a  system  and  cover  all  phases  of  the  design  process. 

2.  Languages  of  different  scope  are  syntactically  and  semantically 
unrelated. 

3.  Few  of  the  languages  are  formally  defined. 

4.  Only  a  few  languages  are  implemented. 

5.  Descriptions  are  represented  by  character  strings  rather  than 
graphically. 

6.  There  exists  no  complete  hardware  design  methodology  to  tell 
how  to  use  HDLs  effectively. 


The  main  emphasis  of  CONLAN  is  to  address  the  first  four 
deficiencies.  CONLAN  itself  is  not  an  HDL,  but  its  primary  objectives  are 
to  1)  provide  a  common  formal  syntactic  and  semantic  base  for  all  levels  of 
hardware  description,  2)  provide  a  means  for  the  derivation  of  user 
languages  from  this  common  base,  and  3)  support  CAD  tools  for 
documentation,  certification,  synthesis,  and  so  on.  Although  many 
concepts  of  existing  CHDLs  appear  in  CONLAN,  it  is  not  intended  as  a 
language  standard,  but  instead  is  a  formal  system  which  allows  designers  to 
construct  HDLs  of  their  choice  in  a  consistent  and  unambiguous  way.  In 
this  way,  the  industry  will  be  able  to  more  efficiently  use  HDLs  in  the 
entire  phase  of  hardware  development. 
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2.2.  Levels  of  Hardware  Description 

CHDLs  have  become  vital  in  the  design  of  microprocessors  and 
related  electronic  equipment.  As  computers  have  become  more  complex, 
tools  have  been  developed  to  aid  the  engineer  in  the  development  of  the 
circuitry  which  makes  up  a  computer  system  at  different  levels.  Six  levels 
of  hardware  description  are  widely  recognized  among  hardware  designers 
[50].  These  are  1)  circuit  level,  2)  logic  gate  level,  3)  register  transfer 
level,  4)  instruction  set  level  or  programming  level,  5)  processor  memory 
switch  level,  and  6)  algorithmic  level.  A  number  of  CHDLs  have  been 
developed  for  use  at  the  various  levels  of  abstraction  of  the  design  of  a 
microprocessor. 

2.2.1.  Circuit  Level 

The  components  described  at  the  circuit  level  are  the  transistors, 
diodes,  resistors,  etc.  which  make  up  the  various  gates  of  an  electronic 
system.  An  electronic  design  is  described  as  the  interconnection  of  these 
components  and  is  the  lowest  level  of  abstraction  recognized  among 
computer  hardware  designers.  (There  exist  lower  levels  which  are  of 
interest  to  engineers  who  build  and  test  these  components,  however,  these 
levels  are  not  usually  used  by  the  computer  hardware  developer.) 
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2.2.2.  Logic  Gate  Level 

The  logic  gate  level  is  the  description  of  a  piece  of  hardware  at  the 
logic  gate  (AND,  OR,  NOT,  etc.)  level.  Its  primary  purpose  is  to  describe 
SSI  (Small  Scale  Integration),  MSI  (Medium  Scale  Integration),  and  some 
LSI  (Large  Scale  Integration)  circuits.  The  behavior  is  given  by  a  set  of 
boolean  equations,  and  timing  is  on  the  order  of  a  gate  delay.  With  the 
advent  of  VLSI  (Very  Large  Scale  Integration),  the  computer  design 
engineer  will  have  less  use  for  this  type  of  representation,  and  will  need  a 
system  that  begins  to  model  the  behavior  of  the  circuit  instead  of  the 
structure. 

2.2.3.  Register  Transfer  Level 

The  register  transfer  level  is  where  most  CHDLs  are  implemented. 
At  this  level,  registers  are  the  basic  component  of  the  system.  These 
languages  model  the  transfer  of  data  between  registers,  and  logical  and 
arithmetic  expressions.  Some  examples  of  CHDLs  at  this  level  are  AHPL, 
DDL,  and  CDL.  Most  CHDLs  operate  at  the  register  transfer  level.  This 
level  has  been  broken  down  into  three  sub-levels  [9].  These  are  1) 
structure  level,  2)  function  level,  and  3)  behavior  level. 
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2.2.3.1.  Structure  Level 

Structure  level  description  consists  of  describing  the  system  using 
actual  hardware  components.  Operators  have  physical  counterparts.  The 
structure  level  partially  corresponds  to  the  logic  gate  level.  The  structure 
level  can  describe  hardware  at  the  logic  gate  level,  but  generally  only  does 
so  when  necessary.  It  typically  uses  components  at  a  higher  level  of 
abstraction. 

2.2.3.2.  Functional  Level 

Descriptions  at  the  functional  level  consist  of  using  actual  hardware 
components  and  their  functional  relationship  rather  than  the  connections 
between  them.  Unlike  the  structure  level,  operators  do  not  have  physical 
counterparts. 

2.2.3.3.  Behavior  Level 

The  behavior  level  describes  the  external  behavior  of  the  system. 
Its  purpose  is  to  describe  the  algorithm  used  by  the  hardware  in  terms  of 
its  input  and  output  functions.  This  level  is  similar  to  some  of  the  higher 
levels  of  abstraction. 
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2.2.4.  Instruction  Set  Level 

ISP  is  an  example  of  a  CHDL  at  the  instruction  set  level.  At  this 
level,  the  instruction  set  of  the  microprocessor  is  simulated.  The  bits  that 
make  up  the  program  being  simulated  are  interpreted  by  a  specific  set  of 
rules,  and  results  are  produced  based  on  these  rules.  This  is  a  functional 
description  of  a  microprocessor  whereas  the  previous  levels  describe  the 
structure  of  the  underlying  hardware.  Using  the  instruction  set  level,  an 
engineer  can  first  develop  a  workable  instruction  set  (behavior  level),  and 
then  concentrate  on  the  hardware  (structure)  level. 

2.2.5.  Processor  Memory  Switch  Level 

The  Processor  Memory  Switch  (PMS)  level  describes  the  system  in 
terms  of  processing  units,  memory  components,  peripherals,  and  switching 
networks.  Only  the  major  properties  of  the  system  are  defined  at  this  level. 
These  properties  include  costs,  memory  capacities,  system  peripherals,  and 
information  flow  rates.  One  use  for  this  level  is  to  determine  the  cost 
effectiveness  of  a  particular  design  for  a  microprocessor.  Another  use  is 
its  application  as  a  formal  feasibility  study  tool  for  the  engineer. 
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2.2.6.  Algorithmic  Level 

The  highest  level  of  abstraction  is  the  algorithmic  level.  At  this 
level,  only  the  algorithm  executed  by  the  hardware  is  important.  This  is  an 
important  concept,  especially  considering  the  complexity  of  circuitry  in 
modern  microprocessors.  The  engineer  can  build  a  module  using  a  lower 
level  of  abstraction.  When  the  module  is  completed,  it  can  be  expressed  as 
an  algorithm  in  order  to  reduce  the  complexity  of  the  simulator 
specification. 

2.3.  Applications  of  CHDLs 

Most  of  the  work  in  the  area  of  CHDLs  deals  with  the  functional  and 
behavior  level  of  the  register  transfer  language  level.  Several  simulators 
exist  on  a  variety  of  computers  which  operate  at  the  functional  and 
behavior  level.  The  operations  which  define  the  hardware  in  some  of  these 
CHDLs  are  quite  complex  both  in  implementation  and  in  the  way  they  are 
used  by  the  hardware  engineer. 

CHDLs  have  important  applications  in  the  computer  aided  design, 
documentation,  and  design  automation  systems.  The  applications  fall  into 
three  main  categories.  These  are  1)  descriptive  tool,  2)  simulation  and 
design  verification,  and  3)  design  automation  and  hardware  synthesis  [63]. 
A  discussion  of  each  application  area  is  presented  next. 
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2.3.1.  Descriptive  Tool 

In  any  complex  system  development  cycle,  a  product  needs  to  be 
described  before  producing  it,  and  while  building  and  testing  it.  Many 
CHDLs  are  intended  as  a  descriptive  tool.  Later  some  of  these  have  been 
modified  for  use  with  the  other  two  application  areas.  After  describing  the 
product,  the  description  must  be  communicated  to  other  members  of  the 
design  team  and  documented.  The  efficiency  of  the  design  team's  efforts 
can  be  increased  with  the  use  of  a  standard  tool.  Desirable  features  include 
a  consistency  check  of  the  documentation,  as  well  as  an  automated 
documentation  revision  system.  As  these  tools  become  more  sophisticated, 
they  will  generate  additional  useful  information. 

2.3.2.  Simulation  and  Design  Verification 

Another  role  of  a  CHDL  is  simulation  and  verification.  As  a  system 
is  being  developed,  its  actions  can  be  simulated  with  a  CHDL  simulator. 
The  simulator  output  can  then  be  checked  with  the  expected  results.  Since 
no  actual  hardware  has  been  built  in  this  phase,  it  is  relatively  easy  to  make 
a  change  to  the  design,  to  correct  a  problem  or  experiment  with  a  different 
design.  Simulating  a  design  can  also  assist  the  engineer  in  verification  of 
the  design.  As  designs  become  more  complex,  formal  proof  that  it  will 
work  with  all  possible  sets  of  input  data  becomes  more  difficult.  With  the 
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help  of  a  CHDL,  the  accuracy  of  a  design  can  be  tested.  One  way  to  do  this 
is  by  fault  injection,  the  process  of  inserting  a  fault  in  the  specification  to 
cause  errors  (by  design)  in  the  simulation  run.  Thus  if  a  catastrophic 
failure  occurs  on  a  certain  type  of  fault,  additional  design  work  is 
necessary  to  reduce  the  impact  of  the  fault  or  reduce  the  chances  of  that 
kind  of  fault  occurring. 

2.3.3.  Design  Automation  and  Hardware  Synthesis 

Additionally,  the  design  process  and  hardware  synthesis  needs  to  be 
automated  to  increase  designer  productivity.  With  a  CHDL,  design 
automation  is  a  realistic  goal.  As  well  as  providing  a  standard  method  of 
describing  a  particular  system,  the  CHDL  can  be  designed  to  produce  a 
specification  for  physical  construction.  In  many  cases  the  hardware 
generated  by  these  systems  is  not  optimal,  and  may  need  hand  optimization. 
However,  as  CHDLs  become  more  sophisticated  they  will  produce  better 
specifications  for  the  physical  construction. 
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Chapter  Three 
Introduction  to  ASIM  II 

3.1.  Purpose  of  ASIM  II 

Although  the  existing  CHDLs  have  a  large  command  set,  a  small 
command  set  which  provides  a  maximum  of  functionality  is  most 
desirable.  Thus  it  is  the  purpose  of  ASIM  II  (Architecture  SIMulator  II)  to 
realize  this  goal.  ASIM  II  (and  its  predecessor  ASIM)  has  a  very  small 
command  set,  namely  ALU,  selector,  and  memory  operations.  With  these 
three  primitives,  it  is  possible  to  represent  nearly  any  hardware  device. 
The  primary  advantage  of  the  small  command  set  is  the  ease  of 
remembering  the  different  commands.  If  the  entire  command  set  is  easily 
learned  by  the  hardware  designer,  a  specification  can  be  easily  written 
without  the  need  to  consult  the  users  manual  for  the  description  of  the 
semantics  and  syntax  of  an  exotic  command  utilized  in  certain  designs. 
This  ease  of  use  enables  the  designer  to  use  ASIM  II  in  place  of  a  larger 
language. 

When  writing  a  simulator  it  is  important  to  consider  that  simulation 
at  this  level  is  very  likely  to  take  considerably  more  execution  time  than  the 
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actual  architecture  would  require.  The  machine  doing  the  simulation  as 
well  as  the  machine  being  simulated  will,  of  course,  make  a  great  deal  of 
difference.  Since  most  work  will  likely  involve  simulating  relatively  new 
architectures  on  an  existing  machine,  simulation  is  expected  to  be  quite 
slow  in  comparison  to  what  the  actual  execution  speed  of  the  simulated 
device  would  be. 

The  major  benefit  of  a  RTL  is  to  allow  the  circuit  designer  to 
produce  a  circuit  using  a  software  system  to  evaluate  the  performance 
characteristics  of  the  design.  Another  benefit  is  in  the  classroom  situation 
where  a  student  will  be  able  to  use  the  simulator  instead  of  or  in  addition  to 
the  actual  hardware  lab.  ASM  II  is  motivated  by  the  need  for  a  simulator 
which  would  run  at  an  acceptable  speed  for  a  significant  specification.  The 
existing  simulator,  ASIM,  provides  an  acceptable  degree  of  usefulness,  but 
its  simulation  time  is  too  slow  to  simulate  a  usable  microprocessor 
specification.  ASIM  was  written  in  Pascal  by  Dr.  Thomas  Pittman  on  the 
Macintosh  computer.  It  was  ported  to  a  Harris  computer  and  later  to  the 
Vax  1 1/780.  ASIM  reads  the  specification  into  tables,  and  produces  a 
simulation  run  by  interpreting  the  symbols  in  the  table.  ASIM  II,  on  the 
other  hand,  produces  Pascal  code  from  the  specification  which  is  then 
compiled  by  a  standard  Pascal  compiler  and  executed.  The  execution  time 
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of  ASIM  II  is  less  than  that  of  ASIM  by  approximately  an  order  of 
magnitude.  This  reduction  is  offset  in  part  by  a  longer  compile  time. 

3.2.  Description  of  Components 

The  three  functional  units  in  ASIM  II  are  1)  ALU  (Arithmetic  and 
Logic  Unit),  2)  Selector,  and  3)  Memory.  These  three  components  are 
sufficient  to  describe  many  different  hardware  projects  ranging  from  a 
simple  counter  to  a  stack  machine  and  beyond.  A  description  of  each  of  the 
components  follows.  See  Appendix  A  for  the  formal  documentation  of  the 
simulator,  and  Appendix  B  for  the  syntax  diagrams  which  define  the 
language. 

The  format  for  an  ALU  is: 

A  name  function  left  right 

where  name  is  the  name  of  the  ALU,  function  is  an  expression  which 
determines  the  operation  to  be  performed  on  left  and  right,  the  two 
operands. 

The  format  for  a  Selector  is: 

S  name  selector  valueO  valuel  value2  . . .  valuen 

where  name  is  the  name  of  the  Selector,  and  the  value  of  selector  forms 
an  index  to  the  appropriate  value  in  the  value  list. 
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The  format  for  a  Memory  is: 

M  name  address  data  operation  number  [initial 
values] 

where  name  is  the  name  of  the  memory,  address  is  the  address  (0  based)  of 
the  memory,  data  is  the  expression  which  gets  stored  in  the  memory  (for  a 
write  operation),  operation  is  the  operation  which  is  performed  on  the 
memory,  number  is  the  number  of  memory  cells,  and  initial  values  is 
an  optional  list  of  values  from  which  the  memory  gets  its  initialization  data. 
Most  fields  in  the  components  may  contain  a  complex  expression 
(see  Appendix  B  for  a  complete  description  of  an  expression  and  where  the 
expression  can  occur).  This  expression  can  be  composed  of  the 
concatenation  of  several  components,  and  numeric  constants.  Thus 
mem. 3. 4,  #01,  count  .1  means  to  concatenate  the  fourth  and  fifth  bits  (bit 
positions  are  zero  based)  of  mem  with  the  binary  string  oi  and  the  second  bit 
of  count  giving  the  result  shown  in  Figure  3.1. 
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mem. 3. 4, #01, count .1 


I  I  I  I  I  I 


Ha 
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1 1 1 1 1 1 1 1 1 

count 


lOIOIOIOIOIOlOlll 


Figure  3.1  Bit  Concatenation 
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Chapter  Four 
ASIM  II  Operation 

4.1.  Primitives 

ASIM  II  has  a  small  instruction  set  with  which  it  is  possible  to 
express  nearly  any  piece  of  hardware.  It  lacks  no  primitive  which  is 
needed  to  form  a  more  complete  command  set  to  describe  digital  electronic 
equipment.  The  primitives  ALU,  selector,  and  memory  have  been  used  to 
describe  a  small  stack  machine  which  is  able  to  execute  a  set  of  stack 
operators.  The  popular  Sieve  of  Eratosthenes  (a  prime  number  generator 
implemented  with  a  standard  algorithm  to  assure  similar  test  conditions 
among  the  various  machines  being  benchmarked)  has  been  implemented  as 
a  series  of  stack  commands  and  is  simulated  using  this  simulator 
specification.  The  stack  machine  implementation  of  the  Sieve  of 
Eratosthenes  is  shown  in  Appendix  D. 

4.2.  Description  of  Primitives 

Each  component  in  the  specification  can  be  replaced  with  a 
hardware  component  when  constructing  the  prototype  of  the  specification. 
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These  hardware  components  can  be  purchased  and  easily  connected 
together  in  the  way  described  by  the  device  description.  A  description  of 
each  primitive  follows. 

4.2.1.  ALU 

The  ALU  primitive  is  a  software  representation  of  a  hardware 
ALU.  In  some  cases,  the  ALU  describes  gates  (NAND,  AND,  OR,  NOT, 
etc.)  and  in  other  cases  an  actual  arithmetic  unit  capable  of  addition, 
subtraction,  multiplication,  division,  and  comparison.  Each  ALU  has  three 
inputs  (see  Section  3.2).  The  function  input  tells  the  ALU  which  operation 
to  perform.  If  the  operation  is  a  constant,  the  ALU  may  be  implemented  as 
a  series  of  gates  which  perform  that  one  function;  otherwise,  an  actual 
ALU  may  be  used,  with  the  function  bits  determining  its  actual  function. 
The  left  and  right  operands  form  the  data  inputs  to  the  ALU,  while  the 
name  contains  the  output  of  the  ALU  for  use  as  input  to  another 
component.  See  Figure  4.1  for  an  example  of  an  ALU  specification  and  the 
code  which  ASIM  II  generates  to  simulate  that  specification.  The  ALU 
named  "alu"  shows  the  generic  code  generated  for  an  ALU.  The  ALU 
named  "add"  shows  the  optimized  code  for  a  function  whose  value  is  a 
constant  and  whose  function  is  to  add  the  left  and  right  operands.   The 
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Specification: 


A  alu  compute  left  3048 
A  add  4  left  3048 


Code  generated: 


alu  :=  dologic (compute,  left,  3048)  ; 
add  :=  left  +  3048; 


Figure  4.1  ALU  Specification  and  Code  Generated  by  ASM  II 

function  dologic  is  shown  in  Appendix  E  with  the  code  generated  for  the 
stack  machine. 

4.2.2.  Selector 

A  selector  is  usually  implemented  as  a  data  selector/multiplexor 
when  the  description  is  used  to  construct  a  hardware  circuit.  The  selector 
input  selects  the  input  (valueO,  valuel, ...,  valuen)  which  is  connected  to  the 
output.  Again,  the  name  of  the  selector  is  used  to  hold  the  output  value  for 
use  as  input  to  another  component.  See  Figure  4.2  for  an  example  of  the 
code  generated  by  ASIM  II. 
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Specification: 

S  selector  index  valueO  valuel  value2  value3 

Code  generated: 

case  index  of 

0 

selector 

=  valueO; 

1 

selector 

=  valuel; 

2 

selector 

=  value2; 

3 

selector 

=  value3 

end; 

Figure  4.2  Selector  Specification  and  Code  Generated  by  ASIM  II 

4.2.3.  Memory 

A  memory  is  a  much  more  complicated  device.  The  hardware 
representation  can  be  implemented  in  a  variety  of  ways  depending  on  the 
actual  use  of  the  memory,  and  the  number  of  cells  in  that  memory.  If  the 
memory  is  a  single  location,  it  will  typically  be  represented  as  a  flip-flop, 
or  a  set  of  flip-flops  to  hold  several  bits,  i.e.  a  register.  If  the  memory  is 
composed  of  several  cells,  it  may  be  represented  as  a  ROM  or  RAM, 
depending  on  the  type  of  operations  that  may  be  performed  on  it. 
Automatic  logic  generation  of  a  circuit  from  the  specification  can  be  quite 
difficult  if  the  designer  wishes  to  have  the  circuit  optimized  to  a  reasonable 
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extent.  However,  the  primary  goal  of  ASIM  II  is  to  simulate  a  design  in 
preparation  of  building  a  prototype.  See  Figure  4.3  for  an  example  of  the 
code  generated  from  an  ASIM  II  specification  of  a  memory.  (See  next 
section  for  a  description  of  the  various  temporary  variables  used.) 

4.3.  Implementation  Notes 

An  ALU  is  implemented  as  a  procedure  call  which  accepts  as  inputs 
the  function,  left,  and  right  operands.  A  case  statement  then  decodes  the 
function,  and  computes  the  result  of  the  function  applied  to  the  left  and 
right  operands. 

A  selector,  consisting  of  a  case  statement  with  the  selector  operand, 
provides  the  index  to  the  list  of  cases.  If  the  value  of  the  selector  exceeds 
the  number  of  cases,  a  runtime  error  will  result.  It  is  up  to  the 
programmer  to  ensure  that  there  are  enough  cases  for  the  range  of  selector 
values. 

Memories  are  implemented  as  a  zero-based  array  of  integers.  If  the 
number  of  memory  locations  is  specified  as  negative,  the  memory  is 
initialized  with  the  initializer  list.  A  memory  in  ASIM  II,  just  like  real 
hardware,  has  a  delay  from  when  it  is  accessed  to  when  it  actually  provides 
the  result  of  that  access.  This  delay  is  one  cycle. 
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Specification: 

M  memory  address  data  operation  -4  12  34  56  7£ 

Code  generated  in  initialization  procedure: 


memory [0] 

=  12 

memory [1] 

=  34 

memory [2] 

=  56 

memory [3] 

=  78 

Code  generated  in  main  program: 

Compute  new  value  and  handle  input  and  output 

case  land (operation,  3)  of 

0:  tempmemory  :=  memory [address] ; 
1 :  begin 

tempmemory  :=  data; 
memory [address]  :  =  data 
end; 
2:  tempmemory  :=  sinput (address) ; 
3:  begin 

tempmemory  :=  data; 
soutput (address,  data) ; 
end 
end;  {case} 


Figure  4.3  Memory  Specification  and  Code  Generated  by  ASM  II 
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Trace  writes 

if  land (operation,  5)  =  5  then 

writeln('   Write  to  memory  at  ' 

address :1,  '  :  ', 

tempmemory : 1 ) ; 

Trace  reads 

if  land (operation,  9)  =  8  then 

writeln  ( '   Read  from  memory  at  ' 

,  address:!,  '  :  ', 

tempmemory : 1 ) ; 

Figure  4.3  (continued) 

To  eliminate  the  need  for  actual  parallel  processing  of  the  components,  the 
components  are  sorted  in  a  dependency  order.  If  the  value  of  a  selector 
requires  the  result  of  an  ALU,  the  ALU's  value  is  computed  first,  etc. 
Memories  are  not  sorted.  Instead,  their  results  are  stored  in  temporary 
memories  (similar  to  the  memory  buffer  register  in  actual  hardware) 
while  the  new  value  is  being  computed. 

The  values  of  the  components  (if  traced)  are  printed  after  their  new 
values  have  been  computed.  In  the  case  of  memories,  the  value  used  in  the 
computation  is  printed  before  it  is  updated  with  the  new  value  it  may  have 
received  during  that  cycle. 
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4.4.  Optimization  Notes 

In  implementing  ASIM  II,  an  emphasis  was  placed  on  optimization 
of  the  code  produced  by  the  compiler  in  an  effort  to  reduce  execution  time. 
This  optimization  has  a  goal  of  reducing  the  number  of  procedure  calls  in 
the  program.  The  generic  procedure  takes  the  function  of  the  the  ALU, 
and  returns  the  value  based  on  the  three  inputs,  namely  function,  left,  and 
right.  If  the  function  is  a  constant,  code  is  generated  which  performs  the 
function  inline,  rather  than  call  the  procedure.  Similarly,  if  the  memory 
operation  is  a  constant,  the  case  structure  is  eliminated  and  only  the 
appropriate  action  is  performed  on  the  memory. 

4.5.  Input  and  Output 

Input  and  output  is  possible  with  ASIM  II,  and  models  actual 
hardware  designs  in  use  today  by  using  memory  mapped  I/O.  Memory 
mapped  I/O  treats  the  input  and  output  as  a  special  case  of  memory.  The 
I/O  is  received  from  the  standard  input  or  sent  to  the  standard  output  in  this 
simulator.  ASIM  II  utilizes  a  procedure  for  the  I/O,  thus  making  changes 
in  the  handling  of  I/O  easy  to  implement.  A  memory  in  the  specification 
can  contain  the  input  values  for  execution  as  well.  For  example,  the  stack 
machine  description  takes  its  input  directly  from  the  specification.  A  RAM 
in  the  description  contains  the  code  which  is  executed.  Its  output  is  sent  to 
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the  standard  output  and  consists  of  the  prime  numbers  generated  by  the 
simulator. 
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Chapter  Five 
Conclusion 


5.1.  Benefits 

ASIM  II  is  an  important  tool  for  the  design  of  a  digital  electronic 
circuit.  It  provides  all  of  the  necessary  primitives  to  express  nearly  any 
circuit  in  a  form  suitable  for  simulation.  Since  the  design  can  be  simulated 
on  a  software  system,  actual  hardware  prototypes  need  not  be  built  until 
later  in  the  design  phase.  Secondly,  it  is  a  documentation  tool  (at  a  low 
level)  useful  for  generating  hardware  that  performs  the  function  described 
in  the  specification.  A  team  of  designers  can  use  this  specification  format 
to  convey  various  designs  to  one  another  in  a  standard  way. 

5.2.  Execution  speed 

The  simulation  time  of  ASIM  II  has  been  reduced  significantly  over 
that  of  its  predecessor  ASIM  (see  Figure  5.1).  The  data  in  Figure  5.1  was 
taken  from  the  compile  and  execution  time  of  the  stack  machine  example  in 
appendices  D  and  E. 
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ASIM 

Generate  tables 

10.8 

Simulation  time 

310.6 

ASIM  II 

Generate  code 

34.2 

Pascal  Compile 

43.2 

Simulation  time 

15.0 

Traditional  Methods 

Generate  Prototype 

100000 

Run  Prototype 

0.01 

Figure  5.1  Execution  time  comparison  (in  seconds)  of  ASIM  and  ASIM  II 

Both  ASIM  and  ASIM  II  executed  the  specification  for  5545  cycles  (the 
maximum  number  of  cycles  allowable  in  this  specification  of  the  stack 
machine).  The  best  of  5  time  trials  was  taken  with  3  of  the  timings  taken 
very  early  in  the  morning  to  reduce  the  effect  of  other  user  activity  causing 
excessive  variations.  ASIM  uses  10.8  seconds  of  cpu  time  to  prepare  the 
tables  necessary  for  simulation.  310.6  seconds  are  used  in  the  actual 
simulation  .  ASIM  II  used  34.2  seconds  to  generate  the  Pascal  code  from 
the  specification,  and  43.2  seconds  to  compile  the  Pascal  code  to  the  object 
code.    The  simulation  used  only  15.0  seconds.    Thus  if  the  simulation 
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preparation  times  are  not  considered,  (the  simulator  is  used  more  often 
than  code  is  generated  and  compiled  for  it)  ASIM  II  runs  approximately  20 
times  faster  than  ASIM.  Including  the  preparation  times  it  is  nearly  2.5 
times  faster.  This  reduction  has  come  at  the  cost  of  increased  preparation 
time  for  large  specifications.  This  includes  the  Pascal  compile  time  to 
translate  the  code  generated  by  the  simulator  into  machine  code.  In 
contrast  to  the  specification  compile  time,  hand  wiring  of  a  prototype 
would  take  several  days.  Execution  of  the  prototype  would  be  so  fast  (real 
time)  that  monitoring  states  in  the  circuit  would  be  difficult.  However,  a 
prototype  is  a  necessary  phase  of  any  hardware  project. 

5.3  Hardware  Construction 

A  hardware  circuit  can  be  easily  built  from  a  hardware 
specification  in  ASIM  II.  Essentially,  ASIM  II  is  a  list  of  hardware 
components  with  the  wiring  interconnection  specified  by  the  names  of  the 
components  and  their  bit  fields.  If  the  bit  field  exists  in  the  specification, 
then  it  is  known  that  only  the  particular  pins  corresponding  to  that 
component  are  hooked  up  to  to  the  named  component.  The  specification  is 
most  like  a  block  diagram  of  the  circuit.  The  connections  between 
components  are  not  labeled  with  pin  numbers  nor  actual  component  types. 
Enough  information  exists  so  that  the  engineer  can  choose  appropriate 
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components  which  perform  the  function  of  the  specified  component.  See 
Appendix  F  for  an  example  of  a  hardware  specification  and  circuit  for  a 
small  10  bit  microprocessor  with  five  instructions  (load,  store,  branch, 
branch  on  borrow,  and  subtract)  and  128  bytes  of  program  and  data 
memory.  Note  that  each  of  the  components  in  the  specification  has  a 
hardware  component  represented  in  the  diagram.  It  should  be  noted  that 
this  is  not  an  optimum  circuit,  but  rather  a  reflection  of  the  ASIM  II 
specification  and  demonstrates  the  ease  of  translating  the  specification  to  an 
actual  hardware  circuit.  Actual  hardware  generation  is  beyond  the  scope 
of  this  thesis,  however,  it  is  appropriate  to  show  a  small  example  to 
demonstrate  the  value  of  ASIM  II  for  larger  projects. 

5.4.  Future  Considerations 

The  ALUs,  selectors,  and  memories  provide  a  slightly  higher  level 
of  abstraction  than  most  other  CHDLs  provide.  This  makes  hardware 
description  somewhat  more  modular  in  that  the  lower  level  primitives  such 
as  gates  are  not  expressed  unless  they  are  necessary  in  the  description. 
Thus,  a  complete  description  is  smaller  in  ASIM  II  than  in  most  of  the 
other  CHDLs. 

As  with  all  software,  there  is  always  room  for  improvement. 
Further  optimization  of  the  code  is  possible  using  heuristics  to  determine 
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which  memories  do  not  need  temporary  variables  in  which  to  store  results 
while  the  new  values  are  computed  for  the  memories. 

Modularity  is  an  important  concept  in  today's  programming 
languages.  ASIM  II,  however,  does  not  have  any  high  level  modularity 
construct.  The  behavior  of  an  electronic  circuit  is  difficult  to  express  in  a 
modular  fashion  without  providing  the  the  actual  description  of  the  module 
and  expanding  that  description  at  compile  time.  As  semiconductor  prices 
continue  to  fall  and  microprocessors  gain  more  features,  modularity  will 
become  more  important.  The  designer  will  be  less  concerned  over  the 
amount  of  silicon  required  for  the  circuit  than  the  additional  time  needed  to 
produce  a  specification  with  fewer  gates  (typically  less  modular  due  to  the 
gate  reduction  techniques). 

ASIM  II  has  become  a  valuable  tool  for  small  digital  hardware 
projects.  With  improved  speed,  and  modularity,  it  could  become  even 
more  useful  for  simulating  hardware  components  at  the  behavior  and 
structure  levels. 
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Appendix  A 
ASIM  II  Documentation 

To  invoke  ASIM  II,  type  sim  [file].  If  file  is  not  specified,  you 
will  be  prompted  for  an  input  file.  File  contains  the  specification  to  be 
compiled.  After  successful  compilation,  type  pc  simulator .  p  in  order  to 
generate  executable  code  (a.out)  from  the  specification. 

File  format: 

The  first  line  must  be  a  comment  line  starting  with  the  '#'  character. 
This  line  is  echoed  to  the  code  file  as  a  comment.  Any  number  of  macros 
may  follow.  A  macro  begins  with  a  '-'  and  is  followed  by  a  name, 
followed  by  a  text  string  which  will  be  substituted  for  the  macro  name  in 
the  definition  of  components.  (No  whitespace  between  '-'  and  name,  and 
no  whitespace  in  macro  string).  A  macro  may  be  placed  anywhere  in  an 
expression  as  long  as  the  macro  string  can  legally  replace  the  macro  name. 
The  macro  name  is  entered  in  the  component  specification  with  a  '-' 
immediately  followed  by  the  macro  name,  and  may  be  part  of  any  string. 
Any  character  except  letters  and  numbers  will  delimit  a  macro  name  from 
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the  rest  of  the  string.  A  macro  may  contain  a  macro  name,  as  long  as  that 
name  has  already  been  defined  (cannot  be  circular  or  recursive). 

The  number  of  cycles  the  simulator  is  to  run  can,  but  need  not  be 
specified.  The  format  is  an  '='  sign  followed  by  a  decimal  integer. 
(Whitespace  between  '='  and  integer).  If  the  number  of  cycles  is  not 
specified,  you  will  be  asked  how  many  cycles  to  execute  at  the  beginning  of 
the  simulation.  After  those  cycles  have  been  executed,  you  will  again  be 
prompted  for  the  cycle  number  to  continue  to. 

A  list  of  all  component  names  follows  with  an  '*'  immediately 
following  each  name  that  is  to  be  traced  at  each  cycle.  A  period  ends  the 
list  of  names.  The  names  may  be  listed  in  any  order.  Those  followed  by  an 
'*',  will  be  printed  in  the  order  listed.  The  component  specification 
follows  the  list  of  names.  Components  consist  of  ALUs  (A),  Selectors  (S), 
and  Memories  (M),  and  may  appear  in  any  order.  The  components  will  be 
sorted  to  resolve  any  dependencies.  Circular  dependencies  will  generate  an 
error  message  providing  a  clue  to  the  component(s)  which  are  involved  in 
the  dependency.  Following  is  a  list  of  the  components: 

A  name  function  left  right 
S  name  address  valueO  valuel  . . .  valuen 
M  name  address  data  operation  number  [valueO  valuel 
. . .  valuen] 
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It  is  up  to  the  user  to  provide  enough  values  for  all  possible  address 
values  in  a  selector.  Otherwise  a  runtime  error  will  result.  If  number  <  0 
then  the  memory  is  initialized  with  the  values  listed.  The  specification 
must  end  with  a  period. 

Notes: 

Fields  must  not  contain  whitespace.  Comments  may  be  placed 
anywhere  in  the  file  where  whitespace  is  permitted.  A  comment  starts  with 
a '{' and  ends  with  a '}'.  Nested  comments  are  not  supported.  A  runtime 
error  will  occur  if  the  number  of  sources  for  the  selector  is  less  than  the 
value  of  the  address,  or  if  a  memory  address  falls  outside  the  declared 
range  which  starts  at  0.  If  the  number  in  memory  is  less  than  zero,  then 
there  must  be  exactly  that  many  initial  values  provided.  All  components 
are  initialized  to  zero  before  simulation  begins  (except  memories  with 
initial  values  listed). 

I/O  Memory  operations  take  the  memory  data  from  standard  input, 
or  send  the  memory  data  to  standard  output,  depending  on  the  read/write 
bit.  If  the  address  (for  both  read  and  write)  is  0,  then  the  data  is  treated  as 
character  data,  if  the  address  is  1,  the  data  is  treated  as  an  integer, 
otherwise  the  data  is  treated  as  an  integer,  and  the  address  read  or  written  is 
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printed.   These  input  and  output  functions  are  handled  as  a  procedure  in 
ASIM  II,  and  may  be  modified  by  the  user  if  some  other  action  is  desired. 

Below  is  a  list  of  ALU  functions  and  memory  operations 


ALU  functions: 

0  0 

1  right 

2  left 

3  NOT(left) 

4  left  +  right 

5  left -right 

6  left  *  2Aright  (shift  left) 

7  left*  right 

8  AND(left,  right) 

9  OR(left,  right) 

10  XOR(left,  right) 

1 1  unused 

12  left  =  right 

13  left  <  right 


Memory  operations: 

0  read 

1  write 

2  input 

3  output 

4  trace  writes 
8  trace  reads 


Functions  12  and  13  evaluate  to  1  if  true,  0  if  false. 
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simulator 


macrodef 


cycle 


i 


component 
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Appendix  B 
ASIM II  Syntax 
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powerof2 


decint 
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number 


7 


subfield 


number 


o 


number 


->(#) ►    bitstring 

->    compref    


B3 


digit 

-KD-* 

-KD-* 

-KD-* 
-KD-* 


hexdigit 


bitstring      <  r 

►fO^l 

i 

decint 

*(™^i          k- 

bitst 

r*o<      r 

ring 

^           J  ■ 

it 

L  ^             alS 

hexint 

fc/Tl      *-■ 

hexc 

*k±/>   i 

Llglt 

powerof2 

*r*i      » 

dec 

rrj        » 

nai 

digit 

-►©- 

-KD- 
-KD- 


w 


Appendix  C 
ASIM  II  Source  Code 


*  *) 

*  Author:  Lester  Bartel  *) 

*  Program  name:     ASIM  II  *) 

*  Date  completed:   7  October  1986  *) 

*) 

*  Description:     ASIM  II  is  an  architecture  simulator  that  *) 

*  reads  an  input  description  from  a  file  and  produces  *) 

*  Pascal  code  which  will  simulate  the  specification.  *) 

*  If  an  error  occurs  in  the  specification,  the  code  *) 

*  generation  ceases,  and  an  error  is  reported  describing  *) 

*  the  error  condition.  *) 

*  *) 

****** *********************************************************) 

program  simulator (input/  output); 

label 

1; 

const 

strsize  -  127;  {max  length  of  string} 
maxcomponents  =  500;  {max  number  of  components} 

type 

charset  =  set  of  char; 

string  =  array [0 .. strsize J  of  char; 

kindtype  =  (alu,  sel,  mem) ; 

caseptr  =  Acasetype; 

casetype  =  record 

casevalue :  string; 

link:  caseptr 
end;  (record} 
valueptr  =  Avaluetype; 
valuetype  =  record 

value:  integer; 

link:  valueptr 
end;  { record} 
nameptr  =  Anametype; 
nametype  =  record 
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name :  string; 
print,  used:  boolean; 
link:  nameptr 
end;  {record} 
compptr  =  Acomptype; 
comptype  =  record 
used:  boolean; 
name:  string; 
link:  compptr; 
case  kind:  kindtype  of 

alu:  (funct/  left,  right:  string) ; 
sel:  (select:  string; 

cases :  caseptr) ; 
mem:  (addr,  data,  opn:  string; 
number:  integer; 
values:  valueptr) 
end;  {record} 
macroptr  ■  "macrotype; 
macrotype  =  record 
name,  macro:  stringy- 
link  :  macroptr 
end;  {record} 

var 

token,  filename,  comment:  string; 

ch:  char; 

donereading,  err,  varflag,  endmacrodef,  gettokenend:  boolean; 

inf,  sim:  text; 

numbers,  hexnums,  letters,  whitespace:  charset; 

numcomponents,  numcycles,  i :  integer; 

nametable,  nptr :  nameptr; 

comptable,  ptr :  compptr; 

macrotable:  macroptr; 

highbits:  array [0.. 31]  of  integer; 

function  length  (a:  string):  integer; 

(*  * 

<*   This  function  returns  the  length  of  the  string  passed  in.   * 
(*  * 

begin 

length  :=  ord<a[0] ) 

end;  {length} 
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procedure  concat  (var  a:  string;  b:  string) ; 

*****************************************************;*********, 

*  i 

*  This  procedure  concatenates  the  string  b  to  the  end  of     ' 

*  string  a,  returning  the  string  a.  ■> 

*  i 

var  index,  lena,  lenb:  integer; 
begin 

lena:=  length (a); 

lenb:=  length(b); 

if  lena  +  lenb  >  strsize  then 
lenb:=  strsize  -  lena; 

a[0]  :=  chr(lena+lenb) ; 

for  index  :=  1  to  lenb  do 
a  [lena+index] :  =  b[index] 
end;  {concat} 

procedure  concatl  (var  a:  string;  b:  char) ; 

(*  *) 

(*   This  procedure  concatenates  the  character  b  to  the  end  of   *) 
(*   the  string  a  returning  the  string  a.  *) 

(*  *) 

begin 

if  length(a)  <  strsize  then  a[0]  :=  chr (length (a) +1)  ; 

a [length (a) ]  :=  b 
end;  {concatl} 

function  strcmp  (strl,  str2:  string):  boolean; 

(* 

(*   This  function  compares  the  two  strings  passed  to  for        < 
(*   equality.   It  returns  a  boolean  value.  ' 

(* 

var  i,  lenl :  integer; 
begin 

if  length (strl)  <>  length (str2)  then 

strcmp  :=  false 
else  begin 
i  :=  1; 

lenl  :=  length (strl) ; 
while  (strl[i]  =  str2[i])  and  (i  <  lenl)  do 

i  :=  i  +  1; 
if  strl[i]  =  str2[i]  then 
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strcmp  :=  true 
else 

strcmp  :=  false 
end;  {if} 
end;  {strcmp} 

procedure  swrt  (var  fil:  text;  a:  string); 

(*  *) 

(*   This  procedure  prints  the  string  a  to  the  file  fil.        *) 
<*  *! 

(**************A**A*********************************************J 

var  i:  integer; 

begin 

for  i:«  1  to  length (a)  do 
write (fil,  a  [i] ) ; 
end;  {swrt} 

function  max(a,  b:  integer):  integer; 

(*  *) 

(*   This  function  returns  the  largest  of  a  and  b.  *) 

(*  *) 

begin 

if  a  >  b  then 

max  :=  a 
else 

max  :=  b 
end;  {max} 

procedure  printcomperr; 

(* 

(*   This  procedure  prints  the  last  component  read  in.   It  is 

{*   used  to  report  which  component  caused  an  error  condition. 

(* 

var  ptr:  compptr; 
begin 

if  not  donereading  then  begin 
ptr  :=  comptable; 
while  ptrA.link  <>  nil  do 

ptr  :=  ptr A. link; 
write ('Last  component  read  is  <'); 
swrt (output,  ptrA .name) ; 
writeln('>  (error  is  in  this  or  the  next  component).1); 


C4 


end;  { if } 
end;  { print comperr } 

function  numberofbits (str :  string) :  integer; 

/*************************************************************** 
(*  * 

(*  This  function  returns  the  number  of  bits  represented  by  * 
{*  the  expression  in  str.  It  is  used  for  code  optimization.  * 
(*  * 

var  i,  n,  m:  integer; 
begin 
n  :=  0; 
m  :=  0; 
i  :=  1; 

while  (i  <-  length (str))  and  (n  <  31)  do  begin 
if  str[i]  in  ['%',  '#']  then  begin 
i  :=  i  +  1; 
m  :=  0; 

while  (i  <=  length (str))  and  (str[i]  in  ['0',  '!']) 
do  begin 

m  :  =  m  +  1  ; 
i  :=  i  +  1 
end;  {while} 
if  3tr[i]  <>  ' . ■  then 

n  :=  n  4-  m 
else  begin 
i  :=  i  +  1; 
m  :=  0; 

while  (str[i]  in  numbers)  and  (i  <=  length(str))  do  begin 
n  :=  m  *  10  +  ord(str[i]) ; 
i  :-  i  +  1 
end;  {while} 
n  :=  n  +  m; 
end;  (if) 
end  (if  %} 

else  if  (str[i]  =  '$')  or  (str[i]  in  numbers)  then  begin 
i  :=  i  +  1; 
while  not (str [i]  in  ['.',  ' ,'])  and  (i  <=  length (str))  do 

i  :=  i  +  1; 
if  (str[i]  =  '.')  and  (i  <-  length (str))  then  begin 
m  :=  0; 
i  :=  i  +  1; 

while  (str[i]  in  numbers)  and  (i  <=  length (str))  do  begin 
m  :-  m  *  10  +  ord(str [i] ) ; 
i  :=  i  +  1 
end;  {while} 
n  :=  n  +  m 
end 
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else 

n  :=  31 
end  (If  $) 

else  if  str[i]  =  '*'  then  begin 
i  :=  i  +  1; 
m  :=  0; 

while  (str[i]  in  numbers)  and  (i  <=  length (str) )  do  begin 
m  :=  m  *  10  +  ord(str[i]); 
i  :=  i  +  1; 
end;  {while } 
n  :=  max(n,  m  +  1) 
end  (if  *) 

else  if  str[i]  in  letters  then  begin 
i  :=  i  +  1; 

while  <(str[i]  in  letters)  or  (str[i]  in  numbers))  and 
(i  <-  length (str) )  do 
i  :=  i  +  1; 
if  (str[i]  =  '.')  and  (i  <=  length (str))  then  begin 
m  :-  0; 
i  :=  i  +  1; 

while  (str[i]  in  numbers)  and  (i  <=  length(str))  do  begin 
m  :=  m  *  10  +  ord (str [i] ) ; 
i  :=  i  +  1 
end;  (while) 

if  (str[i]  -  '.')  and  (i  <=  length(str))  then  begin 
n  :=  n  -  m; 
m  :=  0; 
i  :=  i  +  1; 

while  (str[i]  in  numbers)  and  (i  <=  length(str))  do  begin 
m  :=  m  *  10  +  ord(str[i] ) ; 
i  :=  i  +  1 
end;  (while) 
n  :=  n  +  m  +  1 
end  (if) 
else 

n  :=  n  +  1 
end  (if) 
else 

n  :=  31 
end;  (if  letters) 
i  :=  i  +  1; 
end;  (main  while) 
if  n  >  31  then 

n  :=  31; 
numberofbits  :=  n 
end;  (numberofbits J 
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function  str2num  (a:  string):  integer; 

*************************************************************** 

*  This  function  returns  the  integer  equivalent  of  the  string  * 

*  passed  to  it.   The  string  may  consist  of  the  summation  of   * 

*  any  combination  of  numbers  as  defined  in  the  syntax  chart.  * 

*************************************************************** 

var  i,  j,  k,  1,  m,  len:  integer; 
begin 
j  :=  0; 
i  :=  1; 

len  :=  length (a)  ; 
while  i  <=  len  do  begin 

if  (a[i]  in  numbers)  or  (a[i]  in  ['"',  '$',  '%'])  then  begin 
case  a[i]  of 

'0',  '1',  '2',  '3',  M',  '5',  '6',  •!' ,     '8',  '9'  :  begin 
k  :=  0; 

while  (a[i]  in  numbers)  and  (i  <=  len)  do  begin 
k  :=  k  *  10  +  ord(a[i])  -  ord('O'); 
i  :=  i  +  1 
end;  {while} 
j  :-  j  +  k; 
end;  {case  numbers} 
1  % '  :  begin 

k  :=  0; 
i  :-  i  +  1; 

while  (a[i]  in  ['1',  '0'])  and  (i  <=  len)  do  begin 
k  :-  k  *  2; 

if  a[i]  -  '1'  then  k  :=  k  +  1; 
i  :-  i  +  1 
end;  {while} 
j  :=  j  +  k; 
end;  {case  %} 
' $ '  :  begin 

k  :=  0; 
i  :«  i  +  1; 

while  (a[i]  in  hexnums)  and  (i  <=  len)  do  begin 
k  :=  k  *  16; 
if  a[i]  in  numbers  then 

k  :»  k  +  ord(a[i])  -  ord('O') 
else 

k  :=  k  +  ord(a[i])  -  ord('A')  +  10; 
i  :-  i  +  1 
end;  {while} 
j  :=  j  +  k; 
end;  {case  $} 
1 A '  :  begin 

k  :=  0; 
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i  :=  i  +  1; 

while  (a[i]  in  numbers)  and  (i  <=  len)  do  begin 

k  :=  k  *  10  +  ord(a[i])  -  ord('O'); 

i  :=  i  +  1 
end;  {while} 
1  :=  1; 
for  m  :-   1  to  k  do 

1  :-  1  *  2; 

j  :-  J  +  i; 

end  {case  A} 
end;  {case} 

if  (i  <=  len)  and  (a[i]  <>  '  +  ')  then  begin 
write  ( 'Error .   Malformed  number  '); 
swrt (output,  a) ; 
writeln( ' . ' ) ; 
err  :=  true; 
printcomperr; 
goto  1 
end 
end 
else  begin 

write { 'Error .   Malformed  number  ' ) ; 
swrt (output,  a) ; 
writeln{ ' . ' ) ; 
err  :=  true; 
printcomperr; 
goto  1 
end;  {if} 
i  :=  i  +  1 
end;  {while} 
str2num  :=  j 
end;  {str2num} 

function  numeric  (str:  string) :  boolean; 

IT************************************************************** 

*  * 

*  This  function  determines  if  the  expression  passed  in  as     * 

*  string  is  a  numeric  constant.   It  is  used  for  optimization.* 

*  * 

var  i:  integer; 
begin 

numeric  :=  true; 

for  i  :=  1  to  length(str)  do 

if  not  (str[i]  in  ['+',  '%',  '$',  'A',  '0'..'9',  'A'.-'F'])  then 
numeric  :=  false 
end;  {numeric} 
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function  land  (a,  b:  integer):  integer; 

(*  *) 

(*  This  function  performs  the  bit  and  function  on  the  values   *) 

(*  of  a  and  b.                                          *) 

<*  *) 

type  bitnos  =  0..31; 

bigset  =  set  of  bitnos; 
var  intset:  record  case  boolean  of 

false:  (i,  j:  integer); 
true:   (x,  y:  bigset) 
end; 
begin 

with  intset  do  begin 
i  :=  a; 
j  :=  b; 
x  :-  x  *  y; 
land  :=■=  i 
end 
end  {land}; 

function  f indname  (name :  string) :  compptr; 

(A*************************************************************, 
(*  * 

(*   This  function  finds  the  component  name  and  returns  a       * 
(*   pointer  to  it.  ■* 

<*  '    i 

var  ptr:  compptr; 
begin 

f indname  :=  nil; 

ptr  :=  comptable; 

while  (ptr  <>  nil)  do  begin 

if  strcmp (ptrA .name,  name)  then  findname  :=  ptr; 
ptr  :=  ptrA.link 
end;  {while} 
end;  {findname} 


C9 


procedure  expr(str:  string;  tempflag:  boolean); 

(*  ») 

(*  This  procedure  generates  the  Pascal  code  for  the  expr  in  *) 

(*  str.   If  tempflag  is  true,  it  generates  code  for  the  *) 

(*  temporary  values  for  the  memories.   Otherwise,  code  is  *) 

(*  generated  using  the  subscripted  memory  value.   The  str  *) 

(*  may  be  any  valid  expression  derivable  from  the  syntax  *) 

(*  diagrams.  *) 

<*  *j 

var  fptr:  compptr; 

a,  br  name:  string; 

i/  jr    k,  1*  m,  n,  o,  p,  q,  frombit,  tobit,  bits,  numbits, 

consttotal :  integer; 
fromflag,  toflag,  addflag,  dirtyflag:  boolean; 
begin 

i  :=  length (str) ; 
j  :=  i; 
numbits  :=  0; 
consttotal  :=  0; 
addflag  :=  false; 
dirtyflag  :=  false; 
repeat 

while  (i>0)  and  (str[i]  <>  ',')  do 

i  :=  i  -  1; 
1  :=  i; 

a[0]     :=   chr(j   -   i)  ; 
for  k    :=   i+1   to   j   do 

a[k-l]     :=   str[k]; 
if  a[l]    in    [*$',     '%',     ,A*,     'O'..^']    then  begin      {number} 
m    :=    1; 

while    (m  <=   length (a))    and    (a[m]    <>    *.')    do  begin 
b[m]     :=  a [m] ; 
m    :=  m   +    1 
end;    {while} 
b[0]     :=   chr(m  -   1) ; 
q    :=    0; 

o    :=  str2num(b) ; 

if  <a[mj  =  '.')  and  (m  <=  length (a))  then  begin 
m  :=  m  +  1; 
n  :=  m; 

while  m  <=  length (a)  do  begin 
b  [m  -  n  +  1]  :=a  [m]  ; 
m  :=  m  +  1 
end;  {while} 

b[0]  :=  chr(length(a)  -  n  -  1) ; 
for  p  :=  1  to  str2num(b)  do 
q  :=  q  +  highbits [p] ; 
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consttotal  :=■  consttotal  +  land(o,  q)  *  highbits [numbits] ; 

numbits  :=  numbits  +  str2num(b) 
end 
else  begin 

consttotal  :=  consttotal  +  o  *  highbits [numbits] ; 

numbits  :=  31 
end  {if} 
end  {case  numbers} 

else  if  a[l]  =  *#*  then  begin   {binary  string} 
a[l]  :=  '%'; 

consttotal  :=  consttotal  +  str2num(a)  *  highbits [numbits] ; 
numbits  :=  numbits  +  length{a)  -  1 
end  {case  #} 

else  if  a[l]  in  ['a'.-'z',  'A'.-'Z']  then  begin 
{ component  reference } 
dirtyflag  :=  true; 
fromflag  :=  false; 
toflag  :=  false; 
f rombit  :=  0 ; 
tobit  :=  0; 

if  addflag  then  write (sim,  '  +  ■); 
m  :=  1; 
while  (m  <=  length (a))  and  (a[m]  <>  '.')  do  begin 

name [m]  :=  a [m] ; 

m  :=  m  +  1 
end;  {while} 
name[0]  :=  chr(m  -  1) ; 
fptr  :=  f indname (name) ; 
if  fptr  =  nil  then  begin 

err  :=  true; 

write < 'Error .   Component  <'); 

swrt (output,  name) ; 

writeln(*>  not  found.'); 

goto  1 
end;  {if} 
m  :=  m  +  1; 
n  :-  1; 
if  m  <=  length (a)  then  begin 

while  (m  <=  length (a))  and  (a[m]  <>  *.*)  do  begin 
b  [n]  :=  a  [m]  ; 
n  :=  n  +  1; 
m  :=  m  +  1 

end;  {while} 

b[0]  :=  chr{n  -  1) ; 

fromflag  :=  true; 

frombit  :=  str2num(b); 

DO  :=  m  +  1; 

n  :=  1; 
end;  {if} 
if  m  <=  length (a)  then  begin 


en 


while  m  <=  length (a)  do  begin 
b[n]  :=  a[m] ; 
n  :=  n  +  1; 
m  :=  m  +  1 
end;  {while} 
b[0]  :=  chr(n  -  1) ; 
tobit  :=  str2num(b); 
toflag  :=  true; 
end;  {if} 
if  fromflag  then 

write (sim,  ■ land( ') ; 
fptr  :=  f indname (name) ; 
if  fptr  <>  nil  then 

if  fptr A. kind  =  mem  then 
if  tempflag  then  begin 
write (sim,  'temp' ) ; 
swrt (sim,  fptrA.name) 
end 
else 
begin 

write (sim,  'ljb' ) ; 
swrt (sim,  name) ; 
write (sim,  ' [ ' ) ; 
expr (fptrA -addr,  tempflag) ; 
write (sim,  * ] ' ) 
end  {if} 
else  begin 

write (sim,  'ljb* ) ; 
swrt (sim,  name) 
end;  {if} 
if  fromflag  then  begin 
write (sim,  ' ,  ' ) ; 
bits  :=  highbits [frombit] ; 
if  toflag  then  begin 

for  m  :=  frombit  +  1  to  tobit  do 
bits  :=  bits  +  highbits [m]  ; 
end;  {if} 

writetsim,  bits:l,  ')'); 
end;  {if} 
if  frombit  >  numbits  then 

write (sim,  *  div  ',  highbits [frombit  -  numbits] :1) 
else 

if  numbits  -  frombit  <>  0  then 

writetsim,  '  *  ',  highbits [numbits  -  frombit] :l)j 
if  fromflag  then 
if  toflag  then 

numbits  :=  numbits  +  tobit  -  frombit  +  1 
else 

numbits  :=  numbits  +  1 
else 
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numbits  :=  31; 

addflag  :=  true 
end  {case  letters} 
else  begin 

err  :=  true; 

write { 'Error.   Malformed  expression  ' ) ; 

swrt (output,  str) ; 

writeln{ ' . ■) ; 

printcomperr; 

goto  1 
end;  {case } 
if  numbits  >  31  then  begin 

err  :=  true; 

write ( 'Error .   Too  many  bits  in  '); 

swrt (output,  str) ; 

writeln( ' . ' ) ; 

goto  1 
end;  {if} 
j  :-  i  -  1; 
i  :=  i  -  1 
until  i  <  0; 
if  dirtyflag  then 

if  consttotal  <>  0  then 

write (sim,  '  +  * ,  consttotal : 1) 
else 
else 

write (sim,  consttotal: 1) 
end;  {expr} 

procedure  genf unctions; 

*) 

This  procedure  generates  the  variable  declarations,  memory  *) 
initialization  procedure,  alu  function,  input  function,  *) 
and  output  procedure.  *) 

*) 

var  vptr:  valueptr; 
begin 

{generate  variable  declarations} 

ptr  :=  comptable; 

write (sim,  'var  ' )  ; 

varflag  :=  false; 

repeat 

if  (varflag)  then 

if  (ptrA.kind  in  [alu,  sel] )  then  begin 
write (sim,  ' ,  1 jb' ) ; 
swrt (sim,  ptrA .name) 
end 
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else  begin 

write (sim,  ' ,  temp ' ) ; 
swrt (sim,  ptrA.name) ; 
write (sim,  ',  adr'); 
swrt (sim,  ptrA .name) ; 
write {sim,  ',  data'); 
swrt (sim,  ptrA .name) ; 
write (sim,  ',  opn'); 
swrt (sim,  ptrA.name) 
end 
else 

if  (ptr A. kind  in  [alu,  sel] )  then  begin 
varflag  :=  true; 
write (sim,  'ljb' ) ; 
swrt (sim,  ptrA .name) 
end 
else  begin 

write (sim,  'temp* ) ; 
swrt (sim,  ptrA .name) ; 
write (sim,  ',  adr*); 
swrt (sim,  ptrA .name) ; 
write (sim,  ',  data ' )  , 
swrt (sim,  ptrA.name) ; 
write (sim,  ',  opn'); 
swrt (sim,  ptrA .name) ; 
varflag  :=  true 
end; 
ptr  :-  ptrA .link 
until  ptr  =  nil; 
writeln(sim,  ':  integer;'); 

writeln(sim,  '     cycles,  cyclecount :  integer;'); 
ptr  :-  comptable; 
repeat 

if  ptr A. kind  =  mem  then  begin 
write (sim,  *     ljb* ) ; 
swrt (sim,  ptrA .name) ; 

writeln(sim,  ':  arrayfO..*,  abs (ptrA .number)  -  1:1,  ']  of 
integer; ') 
end;  (if) 
ptr  :=  ptrA.link 
until  ptr  =  nil; 


{generate  bit  and  function} 

writeln (sim) ; 

writeln(sim, 

writeln (sim, 

writeln (sim, 

writeln (sim, 

writeln (sim, 

writeln (sim, 


function  land  (a,  b:  integer) :  integer; 
type  bitnos  =  0..31;'); 

bigset  =  set  of  bitnos;'); 
var  intset:  record  case  boolean  of); 

false:  (i,  j :  integer) ; ' ) 
true :   (x,  y :  bigset)  * ) ; 
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writeln (sim, 
writeln (sim, 
writeln (sim, 
writeln (sim, 
writeln (sim, 
writeln (sim, 
writeln (sim, 
writeln (sim, 
writeln (sim, 


end; ' ) ; 
begin ' ) ; 

with  intset  do  begin'); 
=  a;'); 
-  b;*); 
=  x  *  y;'); 
land  :=  i ' ) ; 
end ' ) ; 
end  { land} ; ' ) ; 


']  :  = 


{generate  procedure  to  initialize  memories} 

writeln (sim) ; 

writeln(sim,  'procedure  initvalues; ') ; 

writeln (sim,  ' var  i :  integer; ' ) ; 

writeln (sim,  'begin* ) ; 

ptr  :-  comptable; 

while  ptr  <>  nil  do  begin 

if  ptrA.kind  =  mem  then  begin 
if  ptr A. number  <  0  then  begin 
vptr  :-  ptr". values; 

for  i  :=  0  to  -ptr" .number  -  1  do  begin 
write (sim,  '   1 jb' ) ; 
swrt (sim,  ptr" .name) ; 
writeln(sim,  '[',  1:1, 
vptr  :=  vptr". link 
end;  {for} 
end 
else  begin 

writeln (sim,  ' for  i 
write (sim,  '   1 jb' ) ; 
swrt (sim,  ptr" .name) 
writeln (sim,  ' [i]  := 
end;  {if} 

write (sim,  '   temp'); 
swrt (sim,  ptr" .name) ; 
writeln (sim,  '  :=  0;') 
end;  {if} 
ptr  :=  ptr" -link 
end;  {while} 
writeln (sim,  'end;  {initvalues} ' ) ; 


vptr" .value: 1, 


:=-  0  to  ',  ptr". number  -  1:1, 


0;') 


do')  ; 


{generate  function  to  calculate  alu  functions} 

writeln (sim) ; 

writeln (sim,  'function  dologic (funct,  left,  right:  integer) : 

integer; ■ ) ; 
writeln(sim,  'const  mask  =  ',  highbits[30]  -  1  +  highbits [30] : 1, 

* ;  * )  ; 
writeln(sim,  'var  value  :  integer;'); 
writeln (sim,  'begin ' ) ; 
writeln (sim,  '   value  :=  0; ' ) ; 
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writeln 
writeln 

writeln 
writeln 
writeln 
writeln 
writeln 
writeln 
writeln 
writeln 
writeln 
writeln 
writeln 
writeln 
writeln 
writeln 
2;'); 
writeln 
writeln 
writeln 
writeln 
writeln 
writeln 


(sim, 
(sim, 
(sim, 
(sim, 
(sim, 
(sim, 
(sim, 
(sim, 
(sim, 
(sim, 
(sim, 
(sim, 
(sim, 
(sim, 
(sim, 
(sim, 

(sim, 
(sim, 
(sim, 
(sim, 
(sim, 
(sim, 


case  funct  of); 

0  :  value  :=  0; ') ; 

1  :  value  :=  right; ' ) ; 

2  :  value  :=  left; *) ; 

3  :  value  :=  mask  -  left;'); 

4  :  value  :=  left  +  right;'); 

5  :  value  :=  left  -  right;'); 

6  :  while  (right  >  0)  and  (left  <>  0)  do  begin'), 

left  :=  land (left  +  left,  mask);*); 
-  left; ') ; 
=  right  -  1 ;  ' )  ; 


9  : 

10: 


value 
right 
end; ' ) ; 
value  : 
value  : 
value  : 
value  : 


left  *  right; ') ; 
land (left,  right);'); 

left  +  right  -  land (left,  right);'), 
left  +  right  -  landdeft,  right)  * 


11:  value  :=  0;  *)  ; 

12:  if  left  -  right  then  value  :=  1; 

13:  if  left  <  right  then  value  :=  1') 
end;  {case} ' ) ; 
dologic  :=  value;'); 
end;  {dologic} ' ) ; 


{generat 
writeln ( 
writeln ( 
writeln ( 
writeln ( 
writeln ( 
writeln ( 
writeln ( 
writeln ( 
writeln ( 
writeln ( 
writeln ( 
writeln ( 
writeln ( 
writeln ( 
writeln ( 

writeln ( 
writeln ( 
writeln ( 
writeln ( 


function  for  input  to  memory) 
sim)  ; 

function  sinput (address :  integer):  integer;'); 
var  datum:  char;'); 

data :  integer; ' ) ; 
begin ' ) ; 

if  address  =  0  then  begin'); 
read (input,  datum) ; ' ) ; 
sinput  :=  ord(datum) ') ; 
end ' ) ; 

else  if  address  =  1  then  begin'); 
read (input,  data) ;  ' )  ; 
sinput  :=  data' ) ; 
end ' ) ; 
else  begin' ) ; 

write (output,  ' ' Input  from  address  '',  address:!, 


sim, 
sim, 
sim, 
sim, 
sim, 
sim, 
sim, 
sim, 
sim, 
sim, 
sim, 
sim, 
sim, 
sim, 

);') 

sim, 
sim, 
sim, 
sim, 


readln (input,  data) ; ' 
sinput  :«■  data;'); 
end ' ) ; 
end;  {sinput} ' ) ; 


{generate  procedure  for  output  from  memory} 
writeln (sim) ; 

writeln (sim,  'procedure  soutput (address,  data : 
writeln (sim,  'begin' ) ; 


integer) ; ' ) ; 
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writeln (sim, 
writeln (sim, 
writeln (sim, 
address : 1, 
writeln (sim^ 


if  address  =  0  then  writeln  (output ,  chr (data) )  ' ) ; 
else  if  address  =  1  then  writeln (output,  data)'); 
else  writeln (output,  ' 'Output  to  address  '', 
1 ',  data:l) ') ; 
end;  {soutput } ' ) ; 


end;  {genf unctions } 

procedure  checkname  (name:  string); 

*********************************************************** 

*  This  procedure  checks  all  names  for  valid  characters.   I 

*  the  first  character  is  not  a  letter,  or  the  remaining 

*  characters  are  not  letters  or  numbers,  then  an  error  is 

*  reported. 
* 
*********************************************************** 

var  start,  i:  integer; 
begin 

if  name[l]  =  '-'  then  start  :=  2 

else  start  :=  1; 

if  not  (name [start]  in  letters)  then  err  :=  true; 

for  i  :=  start  +  1  to  length(name)  do 

if  not  (name[i]  in  letters)  and  not  (name[i]  in  numbers)  then 
err  :-  true; 
if  err  then  begin 

write  ( 'Error .   Component  name  '); 
swrt (output,  name) ; 

writeln ( '  invalid,  use  letters  and  numbers  only. ' ) ; 
goto  1 
end;  {if} 
end;  {checkname} 

procedure  gettoken; 
(************************************************************* 

(* 

(*  This  procedure  gets  each  whitespace  delimited  string  of 

(*  characters  and  returns  them  in  the  global  variable  token. 

(*  Macro  substitution  is  done  here  as  well.   If  a  macro  name 

{*  is  found  in  the  string,  the  actual  text  of  the  macro  is 

(*  substituted  immediately. 

(* 

(************************************************************* 

var  macro:  string; 

ptr  :  macroptr; 
begin 

token[0]  :=  chr(O) ; 
if  gettokenend  then  begin 
token[0]  :=  chr  (1) ; 
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token [1]  :=  ','; 
gettokenend  :=  false 
end 
else  begin 

while  (ch  in  whitespace)  and  (not  eof(inf))  do 
if  ch  =  ' { '  then 
while  ch  <>  ' } ■  do 
read(inf,  ch) 
else 

read(inf ,  ch) ; 
{end  if  end  while) 

while  not  (ch  in  whitespace)  and  (not  eof(inf))  do  begin 
{substitute  macro  name  for  actual  macro  text} 
if  endmacrodef  and  (ch  =  '~')  then  begin 
macro  [0]  :-  chr (0) ; 
concatl (macro,  ch) ; 
read(inf ,  ch) ; 

while  not  (ch  in  whitespace)  and  (not  eof(inf))  and 
(  (ch  in  letters)  or  (ch  in  numbers))  do  begin 
concatl (macro,  ch) ; 
read(inf,  ch) 
end;  {while} 
ptr  :=  macrotable; 
while  (ptr  <>  nil)  and  (not  strcmp (macro,  ptrA.name))  do 

ptr  :=  ptr A. link; 
if  ptr  »  nil  then  begin 
write ( 'Error .   Macro  <■); 
swrt (output,  macro) ; 
writelnO  not  defined.'); 
err  :»  true; 
goto  1 
end 
else 

concat (token,  ptrA .macro) 
end 
else  begin 

concatl {token,  ch) ; 
read(inf,  ch) 
end;  {if} 
end;  {while} 
end;  {if} 

if  (token(ord(token[0] ) ]  =  '.')  and  (ord(token[0] )  <>  1)  then  begin 
token{0]  :=  chr (ord(token[0] )  -  1) ; 
gettokenend  :=  true 
end; 
end;  {gettoken} 


C18 


procedure  addname  (namein:  string;  printflag:  boolean); 
I*************************************************************** 
{*  * 

(*   This  procedure  adds  the  component  name  and  all  of  the  data  * 
(*   associated  with  it  to  the  data  structure.  * 

(*  * 

var  ptr:  nameptr; 
begin 

checkname (namein) ; 
if  nametable  =  nil  then  begin 
new(nametable) ; 
with  nametableA  do  begin 
link  :=  nil; 
name  :=  namein; 
print  :=  printflag; 
used  :=  false 
end;  {with} 
end 
else  begin 

ptr  :=  nametable; 

while  ptrA.link  <>  nil  do  begin 

ptr  :=  ptrA.link; 
end; 

new {ptr A .link) ; 
with  ptrA.linkA  do  begin 
link  :=  nil; 
name  :«•  namein; 
print  :=  printflag; 
used  :■  false 
end;  {with} 
end;  {if} 
end;  {addname} 

procedure  name; 

*************************************************************** 

*  * 

*  This  procedure  reads  the  component  name  from  the  input     * 

*  file.  * 

*  * 
*************************************************************** 

begin 

while  token[l]  <>  '.'  do  begin 

if  token [length (token) ]  =  '*'  then  begin 
token[0] :«  chr (ord(token[0] )-l) ; 
addname (token,  true) 
end 
else 
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addname (token,  false) ; 
gettoken; 
end;  {while} 
gettoken; 
end;  {name} 

procedure  macrodef; 
{*************************************************************** 

(*  * 

(*   This  procedure  reads  and  stores  the  macro  definition  in    * 
(*   the  macro  data  structure.  * 

(*  * 

(*************************************************************** 

var  ptr:  macroptr; 
begin 

checkname (token) ; 
new (macrotable) ; 
with  macrotableA  do  begin 
link  :=  nil; 
name  :=  token; 
gettoken; 
macro  :=  token 
end;  {with} 
ptr  :=  macrotable; 
gettoken; 

while  token  [1]  =  ' -*•  do  begin 
checkname (token) ; 
new (ptr A. link) ; 
ptr  :=-  ptr A. link; 
with  ptrA  do  begin 
link  :-  nil; 
name  :=  token; 
endmacrodef  :=  true; 
gettoken; 

endmacrodef  :=  false; 
macro  :=  token 
end;  {with} 
gettoken 
end;  {while} 
end;  {macrodef} 

procedure  cycle; 
*************************************************************** 

*  * 

*  This  procedure  gets  the  number  of  cycles  which  are  to      * 

*  be  simulated.  * 

*  * 
*************************************************************** 


C20 


begin 

gettoken; 

numcycles  :=  str2num (token) ; 

gettoken 
end;  {cycle} 

procedure  readit ; 
************************************************************** 
* 

*  This  procedure  reads  the  input  file,  calling  any  necessary 

*  support  procedures.   It  places  the  specification  in  the 

*  data  structure  for  processing  by  other  procedures. 

************************************************************** 

var  nptr:  nameptr; 

flag:  boolean; 

vptr,  ovptr:  valueptr; 

cptr,  ocptr :  caseptr; 
begin 

endmacrodef  :=  false; 
comment [0]  :=  chr (0)  ; 
repeat 

read (inf ,  ch) ; 

concatl (comment,  ch) 
until  eoln(inf); 

writeln (sim,  'program  simulator (input ,  output) ; ') ; 
if  comment [1]  <>  '#'  then  begin 

err:=  true; 

writeln ( 'Error.   Comment  required. ' ) ; 

goto  1 
end 
else  begin 

write (sim,  ' { ' ) ; 

swrt (sim,  comment) ; 

writeln (sim,  ' J ' ) ; 
end;  { if } 
ch:=  '  '; 
gettoken; 

if  token [1]  =  '-'  then  macrodef; 
endmacrodef  :=  true; 
numcycles  :=  0 ; 
if  token [1]  =  '='  then  cycle; 
name ; 
while  token[l]  <>  '.'  do  begin 

if  (length (token)  =1)  and  (token [1]  in  [ 'A',  'S' ,  'M' ] )  then  begin 
ptr  :=  comptable; 
if  ptr  =  nil  then  begin 
new (ptr) ; 
comptable  :=  ptr 
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end 

else  begin 

while  ptrA.link  <>  nil  do 

ptr  :=  ptrA . link; 
new  (ptrA . link) ; 
ptr  :*»  ptrA.link 
end;  {if} 

with  ptrA  do  begin 
link  :=  nil; 
used  :=  false; 
i  :=  0; 

numcomponents  :=  numcomponents  +  1; 
case  token [1]  of 
'A*  :  kind  :=■  alu; 
'S'  :  kind  :=  sel; 
■M'  :  kind  :=  mem 
end;  {case} 
case  kind  of 
alu  :  begin 

gettoken; 
name  :=  token; 
gettoken; 
funct  :=  token; 
gettoken; 
left  :=  token; 
gettoken; 
right  :=  token; 
gettoken; 
end; 
sel  :  begin 

gettoken; 
name  :=  token; 
gettoken; 
select  :=  token; 
i:=  0; 
gettoken; 
repeat 

new(cptr) ; 

cptrA .casevalue  :=  token; 

cptrA.link  :=  nil; 

if  i  =  0  then 

ptr A . cases  :=  cptr 
else 

ocptrA.link  :=  cptr; 
ocptr  :=  cptr; 
i  :=  i  +  1; 
gettoken 
until  <token[l]  in  ['A',  'S',  'M*,  '-'])  and 
(length (token)  =  1) ; 
end; 
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mem  :  begin 

gettoken; 
name  :=  token; 
gettoken; 
addr  :=  token; 
gettoken; 
data  :=  token; 
gettoken ; 
opn  :=  token; 
gettoken; 

if  token[l]  =  '-'  then  begin 
for  i  :=  2  to  length (token)  do 

token [i-1]  :=  token(i]; 
token[0]  :=  chr (ord (token [0] )  -  1) ; 
number  :=  - {str2num (token) ) ; 
for  i  :=  0  to  abs (number)  -  1  do  begin 
gettoken; 
new(vptr) ; 
if  i  =  0  then 

values  :=  vptr 
else 

ovptrA.link  :=  vptr; 
ovptr  :=  vptr; 

vptrA. value  :=  str2num (token) ; 
vptr^.link  :=  nil 
end;  {for  J 
end 
else 

number  :=  str2num (token) ; 
gettoken; 
end; 
end;  {case} 
nptr  :=  nametable; 
repeat 

flag  :=  strcmp (nptr A. name,  name) ; 
if  flag  then  begin 
used  :=  true; 
nptr A. used  :=  true 
end 
else 

nptr  :=  nptr A. link; 
until  flag  or  (nptr  -  nil) ; 
end;  (with) 
end 

else  begin 
err:=  true; 

write ( 'Error .   Component  expected.   Got  <')  ; 
swrt (output,  token) ; 
writeln ( ' >  instead . ' ) ; 
printcomperr; 
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goto  1 
end; 
end;  {while}; 
writeln {numcomponents : 1 , 
end;  {readit} 


components  read. ' ) ; 


procedure  checkdcl; 

********************** 


******************************** 


*  This  procedure  checks  the  declarations  of  the  components.   * 

*  if  a  component  is  declared  but  not  used,  or  used,  but  not   * 

*  declared,  a  warning  message  is  issued.   Code  generation    * 

*  continues .  * 

*  * 
*************************************************************** 


var  nptr:  nameptr; 
cptr:  compptr; 
begin 

nptr  :=  nametable; 
repeat 

with  nptrA  do  begin 

if  not  used  then  begin 
write ( 'Warning:  ' ) ; 
swrt (output,  name) ; 

writeln('  declared  but  not  defined.') 
end;  {if} 

nptr  :=  nptrA.link 
end;  {with} 
until  nptr  =  nil; 
cptr  :=  comptable; 
repeat 

with  cptrA  do  begin 

if  not  used  then  begin 
write ( 'Warning:  ' ) ; 
swrt (output,  name) ; 

writeln('  defined  but  not  declared.') 
end;  {if} 

cptr  :=  cptr A. link 
end;  {with} 
until  cptr  =  nil 
end; 
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function  compare  (a,  b:  string):  boolean; 

<* 

(*  This  function  breaks  the  expression  in  b  into  the 

(*  individual  pieces,  and  compares  these  pieces  with  the 

(*  string  a.   If  the  any  part  of  b  is  in  a,  then  compare 

(*  returns  true. 

(* 

var  i,  j :  integer; 

c:  string; 
begin 
i  :=  1; 

compare  :=  false; 
while  i  <=  length (b)  do  begin 
j  :=  1; 
if  b[i]  in  letters  then  begin 

while  ((b[i]  in  letters)  or  (b[i]  in  numbers))  and 
(i  <=  length (b) )  do  begin 
c[j]  :=  b[i]; 
j  :«  j  +  1; 
i  :=  i  +  1 
end;  (while} 
c[0]  :=  chr(j  -  1) ; 
if  strcmp (a,  c)  then 
compare  :=  true; 
end;  {if} 
i  :«  i  +  1; 
end;  {while} 
end;  {compare} 

function  dependent  (a,  b:  compptr) :  boolean; 

<*  *) 

(*   This  function  returns  true  if  the  component  a  depends  on    *) 
(*   the  value  of  component  b.  *) 

(*  *) 

var  c:  string; 

cptr:  caseptr; 

begin 

dependent  : =  false; 
c :=  bA .name; 
with  aA  do 
case  kind  of 

alu:  if  compare (c,  funct)  or  compare (c,  left)  or 
compare (o,    right)  then 
dependent  :=  true; 
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sel :  begin 

if  compare (c,  select)  then  dependent  :=  true; 

cptr  :=  cases; 

while  cptr  <>  nil  do  begin 

if  compare  (c,  cptrA .casevalue)  then 

dependent  :=  true; 
cptr  :=  cptrA.link 
end;  {while } 
end;  {case  sel} 
mem :  dependent  : ■  false ; 
end;  {case} 
end;  { dependent } 

procedure  orderit; 
************************************************************ 
* 

*  This  procedure  sorts  the  alu  and  selector  components  in 

*  dependency  order.   It  also  checks  for  circular 

*  dependencies . 
* 
************************************************************ 

var  i,  j,  k,  num:  integer; 
tempi,  ptr:  compptr; 

a,  b:  array [1 . .maxcomponents]  of  compptr; 
begin 
i  :=  1; 
j  :=  1; 
num  : =  0 ; 
ptr  :=  comptable; 

{break  component  list  into  2  pieces:  one  with  alus  and 
selectors,  and  the  other  with  memories} 
a[l]  :=  nil; 
a[2]  :=  nil; 

while  ptr  <>  nil  do  begin 
case  ptrA.kind  of 
alu,  sel :  begin 

a[i]  :=  ptr; 
i  :=  i  +  1; 
end; 
mem :  begin 

b[j]  :=  ptr; 
j  :=  j  +  1 
end 
end;  {case} 
ptr  :=  ptrA .link 
end;  {while} 
a  [i]  :«■  nil; 
b[j]  :=  nil; 
num  :=  i  -  1; 
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{sort  alus  and  selectors} 
for  k  :=  1  to  num  do 
for  i  :=  1  to  num  do 
for  j  :=  i  to  num  do 

if  dependent (a [i] ,  a[j])  then  begin 
tempi  :=  a  [j]  ; 
a[j]  :=  a[i]; 
a[i]  :=  tempi 
end;  {if} 
{check  for  remaining  dependencies} 
for  i  :=  1  to  num  do 
for  j  :=  i  to  num  do 

if  dependent (a [i] ,  a[j])  then  begin 
err  :=  true; 

write ( 'Error .   Circular  dependency  with  '); 
swrt (output,  a [ j] A .name) ; 
write ( '  and/or  ' ) ; 
swrt (output/  a [i] A .name) ; 
writeln ('.'); 
goto  1 
end;  {if} 
j  :=  1; 

if  a[l]  <>  nil  then 
comptable  :=  a[l] 
else  begin 
j  :-  2; 

comptable  :=  b[l] 
end;  {if} 
ptr  :=  comptable; 
i  :=  2; 

while  a[i]  <>  nil  do  begin 
ptr A. link  :=  a [i] ; 
ptr  :=  a[i]; 
i  :=  i  +  1 
end;  {while} 

while  b[j]  <>  nil  do  begin 
ptr A. link  :=  b[ j] ; 
ptr  :=  b[j]; 
j  :=  j  +  1 
end;  {while} 
ptrA.link  :=  nil 
end;  {orderit} 

procedure  init; 
************************************************************* 

*   This  procedure  initializes  variables . 
************************************************************* 


C27 


begin 

donereading  :=  false; 

nametable  :=  nil; 

comptable  :=  nil; 

macrotable  :=  nil; 

numcomponent s  : =  0  ; 

gettokenend  :=  false; 

varf lag  :=  false; 

numbers  :=  [ '  0  '  .  .  '  9 ' ] ; 

letters  :=  ['a'..'z',  'A'.-'Z']; 

hexnums  : =  [ '  0  '  .  .  '  9  ' ,  *  A  * . . ' F ■ ] ; 

whitespace  :=  [chr(9),  chr(10),  chr(13),  '  ',  '(',  *}']; 

rewrite (sim,  'simulator .p' ) ; 

if  argc  =  2  then 

argv (1,  filename) 
else  begin 

writeln ( 'Enter  name  of  input  file.'); 

i:=  0; 

repeat 

read(filename [i] ) ; 
i:=i+l 

until  eoln 
end; 

reset (inf ,    filename) ; 
write ( 'Reading  file  '); 
for  i  :=  0  to  20  do 

write (filename [i] )  ; 
writeln; 

highbits[0]  :=  1; 
for  i  :=  1  to  31  do 

highbits[i]  :=  highbits [i-1]  *  2; 
end;  (init} 

procedure  gencode; 
***************************************************************) 

*  *) 

*  This  procedure  generates  the  Pascal  code  for  the  main      *) 

*  program  of  the  simulator.  .    *) 

*  *) 

va  r  f pt  r :  c  omppt  r ; 

flag,  f lag2 :  boolean; 
cptr:  caseptr; 
mask :  integer; 
begin 

mask  :=  highbits [30]  -  1  +  highbits [30] ; 

{generate  main  program} 

writeln (sim) ; 

writeln (sim,  'begin' ) ; 
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write In (sim,  ' init values; ■ ) ; 
write (sim,  'cycles  :=  ' ); 
writeln (sim,  numcycles :  1,  ' ; ' ) ; 

if  cycles  =  0  then  begin'); 

writeln {' 'Number  of  cycles  to  trace'1);' 


writeln (sim, 
writeln(sim, 
writeln (sim, 
writeln (sim, 
writeln (sim. 


read (cycles) ;  ' )  ; 
end; ' ) ; 

cyclecount  :■  0;'); 


{start  of  main  loop} 

writeln (sim,  'while  cyclecount  <=  cycles  do  begin'); 

{generate  assignments  to  components  J 
ptr  :-  comptable; 
while  ptr  <>  nil  do  begin 
case  ptrA.kind  of 
alu:  begin 

with  ptrA  do  begin 

if  numeric (funct)  then 
case  str2num (funct)  of 
0 :  begin 

write (sim,  ' 1 jb' ) ; 
swrt (sim,  name) ; 
writeln (sim,  '  :=  0 ; ' ) 
end; 
1 :  begin 

write (sim,  ' 1 jb' ) ; 
swrt (sim,  name) ; 
write (sim,  '  :=  ' )  ; 
expr(right,  true) ; 
writeln (sim,  ' ; ' ) 
end; 
2 :  begin 

write (sim,  ' 1 jb ' ) ; 
swrt (sim,  name) ; 
write (sim,  '  :=  ' ) ; 
expr(left,  true) ; 
writeln (sim,  ' ; ' ) 
end; 
3 :  begin 

write (sim,  *  1 jb' ) ; 
swrt (sim,  name) ; 
write (sim,  '  :=  ',  mask : 1,  *  - 
expr(left,  true) ; 
writeln (sim,  ' ; ' ) 
end; 
4 :  begin 

write (sim,  ' 1 jb' ) ; 
swrt (sim,  name) ; 
write (sim,  '  :=  ' )  ; 
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expr (left,  true) ; 

write (sim,  '  +  ■ ) ; 

expr (right,  true) ; 

writeln (sim,  ' ; ' ) ; 
end; 
begin 

write (sim,  'ljb' ) ; 

swrt (sim,  name) ; 

write (sim,  '  :=  ' ) ; 

expr (left,  true) ; 

write (sim,  *  -  * )  ; 

expr (right,  true) ; 

writeln (sim,  ' ; ' ) ; 
end; 
begin 

write (sim,  ' ljb ' ) ; 

swrt (sim,  name) ; 

write (sim,  '  :=  dologic(6,  '); 

expr (left,  true) ; 

write (sim,  ' ,  ' ) ; 

expr (right,  true) ; 

writeln (sim,  ■ ) ; ' ) 
end; 
begin 

write (sim,  ' 1 jb' ) ; 

swrt (sim,  name) ; 

write (sim,  '  :=  ' ) ; 

expr  (left,  true) ; 

write (sim,  '  *  ' ) ; 

expr (right,  true) ; 

writeln (sim,  ' ; * ) 
end; 
begin 

write (sim,  ■ 1 jb ' ) ; 

swrt (sim,  name) ; 

write (sim,  '  :=  ' ) ; 

write (sim,  ' land( ' ) ; 

expr (left,  true) ; 

write (sim,  ' ,  ■ ) ; 

expr (right,  true) ; 

writeln (sim,  ' ) ; ' ) 
end; 
begin 

write (sim,  ' ljb ' ) ; 

swrt (sim,  name) ; 

write (sim,  '  :=  ' ) ; 

expr(left,  true) ; 

write (sim,     '    +    ' ) ; 

expr (right,    true) ; 

write (sim,     '    -   land('); 
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expr (left,  true) ; 

write (sim,  ' ,  ' ) ; 

expr (right,  true) ; 

writeln (sim,  ' ) ; ' ) 
end; 
10 : begin 

write (sim,  ' ljb* ) ; 

swrt (sim,  name) ; 

write (sim,  *  :=  ' ) ; 

expr (left,  true) ; 

write (sim,  '  +  ' ) ; 

expr (right,  true) ; 

write (sim,  '  -  land('); 

expr (left,  true) ; 

write (sim,  ' ,  ' ) ; 

expr (right,  true) ; 

writeln (sim,  ' ) ; ' ) 
end; 
11 : begin 

write (sim,  'ljb' ) ; 

swrt (sim,  name) ; 

writeln(sim,  '  :=  0;') 
end; 
12 : begin 

write (sim,  'if  * )  ; 

expr (left,  true) ; 

write (sim,  '  =  ' )  ; 

expr (right,  true) ; 

write (sim,  ■  then  ljb'); 

swrt (sim,  name) ; 

writeln (sim,  '  :=  1 ' )  ; 

write (sim,  '   else  ljb'); 

swrt (sim,  name) ; 

writeln(sim,  '  :=  0;') 
end; 
13 : begin 

write (sim,  'if  ' )  ; 

expr (left,  true) ; 

write (sim,  '  <  ' )  ; 

expr (right,  true) ; 

write (sim,  '  then  ljb' ) ; 

swrt (sim,  name) ; 

writeln (sim,  '  :=  1 ' ) ; 

write (sim,  '   else  ljb'); 

swrt (sim,  name) ; 

writeln (sim,  '  :=  0;') 
end 
end  { case  optimize  alu  functions } 
2lse  begin 

write (sim,  ' 1 jb' ) ; 
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swrt (sim,  narae) ; 
write (sim,  ■  :=  dologic ( ' ) ; 
expr (funct,  true) ; 
write (sim,  ■ ,  ' ) ; 
expr {left,  true); 
write (sim,  ', 
expr (right,  true) ; 
writeln (sim,  ');*); 
end;  {if} 
end;  {with} 
end;  {case  alu} 
sel:  begin 

write (sim,  'case  '); 

expr (ptrA .select,  true) ; 

writeln  (sim,  *  of); 

i  :-  0; 

cptr  :=  ptrA. cases; 

while  cptr  <>  nil  do  begin 

write(sim,  '   ',  i:l,  '  :  ljb'); 
swrt (sim,  ptrA.name) ; 
write (sim,  '  :=  ' ) ; 
expr (cptr A .casevalue,  true) ; 
writeln (sim,  * ; ' ) ; 
cptr  :=  cptrA.link; 
i  :=  i  +  1 
end;  {while} 
writeln (sim,  'end; ' ) ; 
end;  {case  sel} 
mem :  ; 
end;  {case} 
ptr  :=  ptrA.link 
end;  {while} 

{generate  trace  statements } 
nptr  :=  nametable; 

writeln (sim,  ' write ( ' 'Cycle  ' ' ,  cyclecount : 3) ; ' ) ; 
while  nptr  <>  nil  do  begin 
if  nptrA. print  then  begin 
write  (sim,  ■  write  C'  '); 
swrt (sim,  nptrA .name) ; 
write (sim,  *=  ' ' ,  ' ) ; 
fptr  :=  findname (nptr A .name) ; 
if  fptr  <>  nil  then 

if  fptrA.kind  =  mem  then  begin 
write (sim,  'temp' ) ; 
swrt (sim,  nptrA .name) 
end 
else  begin 

write  (sim,  '1  jb' )  ,* 
swrt (sim,  nptrA .name) 
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end;  {if} 
writeln  (sim,  ■  :  1) ;  ' ) 
end;  {if} 

nptr  :=  nptrA.link 
end;  {while } 
writeln (sim,  'writeln; ' ) ; 

{assign  temporary  memory  values  (adr,  data,  opn) } 

ptr  :=  comptable; 

while  ptr  <>  nil  do  begin 

if  ptr". kind  =  mem  then  begin 

write (sim,  ' adr ' ) ; 

swrt (sim,  ptrA .name) ; 

write (sim,  '  :=  ' ) ; 

expr (ptrA .addr,  true) ; 

writeln (sim,  ' ; ■ ) ; 

write (sim,  'data ' ) ; 

swrt (sim,  ptrA .name) ; 

write(sim,  '  :=  temp'); 

swrt (sim,  ptrA .name) ; 

writeln (sim,  ' ; ' ) ; 

write (sim,  'opn' ) ; 

swrt (sim,  ptrA .name) ; 

write (sim,  '  :=  ■ ) ; 

expr (ptrA .opn,  true) ; 

writeln (sim,  ' ; ' ) 
end;  {if} 
ptr  :=  ptrA.link; 
end;  {while } 

{assign  memories  their  new  values} 

ptr  :=  comptable; 

while  ptr  <>  nil  do  begin 

if  ptrA.kind  =  mem  then  begin 
if  numeric (ptr A .opn)  then  begin 

case  land (str2num(ptrA .opn) ,  3)  of 

0  :  begin 

write (sim,  'temp  * ) ; 
swrt (sim,  ptrA .name) ; 
write (sim,  '  :=  ljb' ) ; 
swrt (sim,  ptrA.name) ; 
write (sim,  ' [adr' ) ; 
swrt (sim,  ptrA.name) ; 
writeln (sim,  ' ] ; ' ) 
end; 

1  :  begin 

write (sim,  'temp') ; 
swrt (sim,  ptrA .name) ; 
write (sim,  *  :=  ' ) ; 
expr (ptrA. data,  true) ; 
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writeln (sim,  ' ;  ' )  ; 
write (sim,  ■ 1 jb ' ) ; 
swrt (sim,  ptrA .name) ; 
write (sim,  ' {adr ' ) ; 
swrt (sim,  ptrA .name) ; 
write (sim,  •]  :=  temp'); 
swrt (sim,  ptrA .name) ; 
writeln (sim,  ' ; ' ) 
end; 

2  :  begin 

write (sim,  'temp' ) ; 
swrt (sim,  ptrA .name) ; 
write (sim,  ■  :=  sinput('); 
expr (ptrA .data,  true) ; 
writeln (sim,  ' ) ; ' ) 
end; 

3  :  begin 

write (sim,  'temp' )  ; 

swrt (sim,  ptrA .name) ; 

write (sim,  '  :=  ' ) ; 

expr (ptrA .data,  true) ; 

writeln (sim,  ' ; ' ) ; 

write (sim,  'soutput ( ' ) ; 

expr (ptrA. data,  true) ; 

write (sim,  ' ,  temp ' ) ; 

swrt (sim,  ptrA .name) ; 

writeln (sim,  ' ) ; ' ) 
end 
end  {case} 
end 
else  begin 

write(sim,  'case  land(opn'); 
swrt (sim,  ptrA.name) ; 
writeln  (sim,  ',  3)  of); 
write (sim,  '   0:  temp*); 
swrt {sim,  ptrA .name) ; 
write (sim,  ■  :=  ljb' ) ; 
swrt (sim,  ptrA .name) ; 
write (sim,  ' [adr' ) ; 
swrt (sim,  ptrA .name) ; 
writeln (sim,  '];'); 
writeln (sim,  '   1 :  begin' ) ; 
write (sim,  '       temp'); 
swrt (sim,  ptrA .name) ; 
write (sim,  *  :=  ' ) ; 
expr {ptrA. data,  true) ; 
writeln (sim,  ' ; ' ) ; 
write (sim,  '       ljb'); 
swrt (sim,  ptrA .name) ; 
write (sim,  ' [adr' ) ; 


C34 


swrt (sim,  ptrA .name) ; 
write {aim,  ']  :=  temp'); 
swrt (sim,  ptrA .name) ; 
writeln (sim,  ' ; ' ) ; 
writeln  (sim,  '      end; ' ) ; 
write (sim,  '   2 :  temp' ) ; 
swrt (sim,  ptrA .name) ; 
write (sim,  '  :=  sinput (adr ' ) ; 
swrt (sim,  ptrA -name) ; 
writeln (sim,  ');'); 
writeln (sim,  '   3:  begin'); 
write (sim,  '       temp'); 
swrt (aim,  ptrA .name) ; 
write (sim,  '  :=  ' ) ; 
expr (ptrA .data,  true) ; 
writeln (sim,  ' ; * ) ; 
write {sim,  '       soutput {adr ' ) ; 
swrt (sim,  ptrA .name) ; 
write (sim,  ' ,  temp' ) \ 
swrt (sim,  ptrA .name) ; 
writeln (sim,  ');'); 
writeln {sim,  '     end' ) ; 
writeln (sim,  'end;  {case} ' ) 
end; 

(generate  code  to  trace  writes} 

flag  :=  false; 

flag2  :=  false; 

if  not  (numeric (ptrA .opn) )  and 

(numberofbits (ptrA.opn)  >=  3)  then 

flag  :=  true 
else 

if  numeric (ptrA . opn)  then 

if  land {str2num(ptrA. opn) ,  4)  =  4  then 
flag2  :=  true; 
if  flag  then  begin 

write (sim,  'if  land( ' ) ; 

expr {ptrA. opn,  true) ; 

writeln (sim,  ',  5)  =5  then'); 

write (sim,  '   ' ) 
end; 
if  flag  or  flag2  then  begin 

write (sim,  ' writeln (•'   Write  to  '); 

swrt (sim,  ptrA .name) ; 

write (sim,  '  at  ' ' ,  ' ) ; 

expr (ptrA .addr,  true) ; 

write (sim,  ' : 1,  ' '  :  ' ' ,  ' ) ; 

expr (ptrA .name,  true) ; 

writeln (sim,  '  :1) ;  ' ) 
end;  {if} 
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{generate  code  to  trace  reads) 

flag  :=  false; 

flag2  :=  false; 

if  not  (numeric (ptrA .opn) )  and  (number of bits (ptrA .opn)  >=4)  then 

flag  :-   true 
else 

if  numeric (ptrA. opn)  then 

if  land(str2num (ptrA .opn) ,  8)  =  8  then 
flag2  :=  true; 
if  flag  then  begin 

write (sim,  ' if  land( ' ) ; 

expr (ptrA. opn,  true) ; 

writeln (sim,  ' ,  9)  =8  then' ) ; 

write (sim,  '   ') 
end; 
if  flag  or  flag2  then  begin 

write (sim,  ■ writeln (*'   Read  from  '); 

swrt (sim,  ptrA .name) ; 

write (sim,  '  at  '",  '); 

expr (ptrA .addr,  true) ; 

write (sim,  ■  :1,  '  '  :  '*,  ' ); 

expr (ptrA .name,  true) ; 

writeln (sim,  ■  :  1)  ;  T ) 
end;  (if) 

end;  { if } 
ptr  :=  ptrA . link 
end;  {while } 

{generate  code  to  check  for  end  of   loop} 


writeln (sim, 
writeln (sim, 
writeln (sim, 
writeln (sim, 
writeln (sim, 
writeln (sim, 


cyclecount  :=  cyclecount  +  1; ' ) ; 

if  cyclecount  =  cycles  +  1  then  begin'); 

writeln (' 'Continue  to  cycle  (0  to  quit)''); 

read (cycles) ; ' ) ; 
end; ' ) ; 
end;  {while } ' ) ; 


{end  of  main  loop} 

writeln (sim,  'end. ' ) ; 
end;  {gencode} 

begin  {main} 
init; 
readit ; 

donereading  :=  true; 
writeln ( 'Sorting  components .') i 
orderit; 
checkdcl; 
writeln ( 'Generating  code.'); 
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genf unctions; 

gencode ; 
1: 

if  err  then 

writelnf 'Error  in  program  (no  code  generated).1); 
end. 
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Appendix  D 
Example  Stack  Machine  Simulator  Specification 


#  Itty  Bitty  Stack  Machine  Simulator  Specification 


bit  functions} 
#000000000000  {=zero.0.~k} 

high  bit  position  in  LDC  loop) 

high  bit  of  RAM  address} 

I/O  select  bit  in  RAM  address} 

~d  selects  right  operand  for  alu} 

~d  selects  fp  to  ALD  right} 

~d..~dd  selects  write  data} 

0..~st  selects  next  state) 

~a  signals  absolute  addressing} 

~f  signals  frame  pointer  update} 

~g  signals  goto,  not  increment} 

~i  signals  increment  or  branch} 

~1  loads  left  from  ram} 

~o  signals  pop,  not  push;  ~z  adds, 

~p  signals  stack  pointer  update} 

~r  loads  right  from  ram} 

~s  selects  state  from  opcode+n} 

~v  selects  frame  pointer  to  load,  not  1  to  add} 

~w  writes  into  stack  ram} 

~w  selects  LDC  loop  test,  not  BZ} 

~x  enables  condition  test} 

~y  selects  frame  offset  for  ram  address} 

~z  indicates  escape;  current  opcode} 


{Macro 

-pack 

~k 

n 

~ra 

n 

~n 

12 

~d 

5 

~dd  7 

-St  4 

~a 

10 

-1 

11 

~g 

9 

-i 

6 

~1 

3 

~o 

1 

~P 

7 

~r 

4 

~s 

12 

~V 

0 

~w 

8 

~x 

13 

~y 

5 

not  loads } 


{Component  list  . . . } 

state  rom  parm  relpc  offset  psp  sp  pushpop  selfp  fp  afp  addr 
ram  op  left  right  neg  selr  alu  exit  write  newpc  pc  prog  ir 
data  newst . 


{Component  specifications. 
M  state  0  newst  1  1 


} 


{write  next  state  (at  end)  } 
A  exit  %110,rom.~w  ram  rom.~w,~pack 


S  newst  rom. ~s .~x, exit . 0 
(000)  parm.0.~st 


{~s  selects  state  from  opcode+n} 
{next  state  from  rom} 
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{001}  parm.0.~st 

(010)  1, rom. ~z, prog. 0.3 

{011}  1, rom. ~z,prog. 0 .3 

{100}  0 

{101}  parm.0.~st 

{110}  0 

{111}  1, rom. ~z,prog.0 .3 

M  pc  0  newpc  rom.~i  1 

A  newpc  %100  relpc  offset 

S  relpc  rom.~a  pc  0 

S  offset  rora.~g  1  left 

M  sp  0  pushpop  rom.~p  1 


{~z  indicates  escape;  current 
opcode} 

{~x  enables  condition  test} 
{~w  selects  LDC  loop  test,  not 
BZ) 


{~i  signals  increment  or  branch} 

{~a  signals  absolute  addressing} 

{~g  signals  goto,  not  increment} 

{~p  signals  stack  pointer 
update} 


A  pushpop  rom. ~z, #0, rom.~o  sp  psp 
S  psp  rom.~v.~z 
{0-2}  0  0  0 


{~v  selects  frame  pointer  to 

load,  not  1  to  add} 
{~o  signals  pop,  not  push;  ~z 

adds,  not  loads) 


{011}  fp 

{100}  1 

{101}  left 

{110}  1 

{111}  right 

M  fp  0  selfp  rom.~f  1 


S  selfp  ir.O  sp  ram 

S  addr  rom.~y  sp  afp 

A  afp  %100  fp  left 
M  left  0  ram  rom.~l  1 
M  right  0  ram  rom.~r  1 
A  neg  %101  0  ram 
S  selr  parm.~d 


{~f  signals  frame  pointer 
update} 

{load  from  current  sp  or  from 
stack} 

{~y  selects  frame  offset  for  ram 
address} 

{frame  offset  =  fp+left} 

{~1  loads  left  from  ram} 

{~r  loads  right  from  ram} 

{negative  of  right} 

{~d  selects  right  operand  for 
alu} 
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{000} 

alu 

{001} 

alu 

{010} 

fp 

{011} 

pc 

{100} 

ir  .0 

{101} 

rara.O 

{110} 

left 

{111} 

neg 

{0}  right 
{1}  fp 

A  alu  op  ram  selr 

M  ir  0  prog  rom.~s  1  {So  that  prog  isn't  held  up,  hack 

remembers  the  value  of  prog  at  fetch 
time.   Note  that  prog  must  be  used  to 
calculate  newst  because  ir  won't  be 
valid  until  the  cycle  following  the 
fetch} 

M  data  0  prog  parm.8  1       {  gets  prog's  value  when  it  is 

data  } 

S  write  parm.~d.~dd         {~d..~dd  selects  write  data} 

{~d  selects  fp  to  ALU  right} 


-k, data. 0.3 


M  ram  addr.0.~m  write  addr .~n, rom. ~w  4096  {~w  writes  into 
stack  ram  the  11  sets  trace  reads  &   writes  } 

S  op  ir.0.3  {Opcode-ALU  function  ROM  follows} 

{0}  0  {1}  0  {2}  %1  {3}  %100  {4}  %1  {5}  %1000  {6}  %1101 
{7}  %1100  {8}  %11  {9}  0  {10}  %100  {11}  %111  {12}  %10 
{13}  %1  {14}  %1100  {15}  %101 

{decode  rom  follows} 
^~s+A~l+A~r+A~i 
^-w 

"~w  {~dd=4}   A~w  {~dd=5} 
^~w+A~y  {goto  $19  so  addr  and  ram  can  bounce 

back} 
^~w 

^~w  {~dd=7} 
~~w  {goto  NEG} 
*~y+A~w+A~l  {goto  SWAP+2} 
~~w  {~dd=6} 

A~z+A~p+A~o+A~v+A~l   A~a+A~g 
A~w 

*~r+A~z+A~p+A~o 
A~x+A~z+A~p+A~o   A~i+A~g 
A~w  {parm=A5+A7+A8,  ~dd=5) 
A~w  {parm=A5+A7+A8} 
A~l+A~z+A~p+A~w 


rom 

state. 0.5 

{00 

fetch} 

{01 

LDZ) 

{02 

LD0} 

{04 

ST. . . } 

{05 

=NOT} 

{06 

=NEG} 

{07 

EQUAL } 

{08 

INDEX. . . } 

{09 

SWAP . . . } 

{0A 

EXIT. . . } 

{0C 

LD} 

{0D 

ST} 

{0E 

BZ} 

{10 

LDC} 

{11 

LDC) 

{12 

SWAP} 

{13 

INDEX} 
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{14  LDC} 
{15  EXIT} 
{16  CALL} 
{17  LDC} 
{18  LDC} 
{19-1E} 

{IF  esc} 
{20  esc} 
{21  LDZ} 
{22  LDO} 
{23  LD1} 
{24  DUPE} 
{25  AND} 
{26  LESS} 
{27  EQUAL} 
{28  NOT} 
{29  NEG} 
{2A  ADD} 
{2B  MPY} 
{2C  LD} 
{2D  ST} 
{2E  BZ} 
{2F  GLOB} 
{30  NOP} 
{31  LDC} 
{32  SWAP) 
{33  INDEX} 
{34  ENTER} 
{  enter  does 
sp  gets  sp 
{35  EXIT} 
{36  CALL} 
{37-3F}  0  0 


-w+A~i  {parm=A5+A7+A8} 
-f+A~p+A~o+A~z 
-w+A~a+A~g  {~dd=3} 
-w+A~i  {parra=A5+A7+A8,  ~dd=5} 
-w+A~i  {parm=A7+A8,  ~dd=4} 
0  0  0  0  0  {19-1E  are  interim  states  (see 

parm)  } 
-s+A~z+A~i 


*~z+A 
^~z+A 
*~z+A 
^~z+A 
*~z+A 
^~z  +  A 

*~Z  +  A 

^~w 
-~w  { 

^~Z  +  A 
^~Z+A 
-~y 
*~Z  +  A 
^~Z  +  A 

^~w  { 


-p 
-P+A~i 

-p+A~i  {goto  LD0+1} 

-p  {goto  LD+1} 

-p+A~o  {goto  NOT,  goto  IE} 

-p+A~0  {goto  EQUAL+1,  goto  ID} 

-p+A~o  {goto  ID} 

-dd=7 } 

-p  +  A~o  {goto  NOT,  goto  IE} 

-p+A~o  {goto  NOT,  goto  IE} 

-p+A~o  {goto  1C} 

-p+A~o  {goto  IB} 
-dd=l } 


A~z+A~p+A~i 

A~z+A~p+A~o  {goto  1A} 

A~z+A~p+A~o 

A~w+A~f+A~p+A~z+A~v  {~dd=2} 
the  following:  write  fp  to  Asp, 
+  left,  increment  pc  } 

A~p+A~o+A~v 

A~i 
0  0  0  0  0  0  0 


fp  gets  sp, 


parm  state. 0.5        {part  2  of  decode  rom} 

{00}  0  0  128+3+A8  160  25  0  224  6  9  192  11  0  0  4  15  25 

{10}  0+A5+A7+A8  16+A5+A7+A8  9  8  17+A5+A7+A8  10  96 

20+A5+A7+A8 
{18}  23+A7+A8  0  18  14  13  7  5  0 

{20}  31  1  2  2  12  30  29  29  0  224  30  30  12  28  27  32 
{30}  0  24  26  19  64  21  22  0  0  0  0  0  0  0  0  0 


M  prog  pc  0  0  -133  {-1024} 
0  0  3  10 


0 

1 

2 

13 


000 
enter  } 
;  count 
ldz  } 
IdO  4  } 
st  } 

I  for(i-0; 

:  flags  [i] 


{program  rom  follows} 
ldl  10  ;  ldc  2  6  } 


-  0 


i<=size; 
=  true  } 


i++) 
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2 

10 
4 
2 
0 

13 
4 
3 

7 
3 
9 
14 
2 

13 

1 

2 

13 

2 

12 

2 

10 
12 

0 
14 

2 

12 

4 

4 

10 
2 

10 
4 
0 

13 
4 
2 

13 


10 

4 
2 

10 
1 
0 


10 


1  0  0  3  10 


10  0  0 


IdO  5   ;  one  less  than  array  addr 

since  1  is  added  immediately  } 
FORI     IdO  1  } 

add  } 

dupe  } 

IdO  1  } 

swap  } 

st  } 

dupe  } 

ldl  10  ;  ldc  26  =  size  +  array 

offset  ) 

equal  } 

ldl  1;  ldc  17  =  endforl  -  fori  } 

neg  } 

bz  } 
ENDFOR1   IdO  5  ;  loc  5  unused,  get 
junk  off  stack  } 

st  > 
;  for  (i=0;  i  <=  size;  i++)  ) 

ldz  } 

IdO  1  ) 

st  } 
;  if  (flags  [i])  } 
FOR2      IdO  1  ;  get  i  } 

Id  } 

IdO  6  ;  get  start  of  flags  } 

add  ) 

Id  ;  get  flags  [i]  } 

ldc  58=S3a     ;  INC  -  IF  } 

bz  } 

;  prime  =  i  +  i  +  3  } 
IF       IdO  1  ;  get  i  } 

Id  } 

dupe  } 

dupe  } 

add  ;  i  +  i  } 

IdO  3  } 

add  ;  this  is  the  prime  number  } 
dupe  } 

IdO  4096;  output  prime  } 
st  } 
dupe  } 

IdO  2  ;  store  prime  } 
st  } 
;  for (k=i+prime;  k  <=  size; 

k+=prime)  ;  flags  [k]  =  false  } 
add  ;  k=i+prime  } 
FOR3    dupe  } 
IdO  6  } 

add  ;  add  array  address  } 
ldz  } 
swap  ) 
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13 
2 

12 

10 
4 
3 
6 
2 

14 
1 
3 
9 

14 
2 

13 


2 

4 

12 

2 

1 

10 

2 

4 

13 

2 

1 

12 

2 

1 

10 

4 

2 

1 

13 

3 

5 

7 

0 

1    0    0    5    13 

9 

14 

0    0 

0    0 

• 

st  ;  flags [k]=0  } 

IdO  2 ;  get  prime  } 

Id  } 

add  ;  k  =  k  +  prime  } 

dupe  } 

ldl  5  ;  ldc  21  =  size  +  1  ) 

less  } 

IdO  ;  ENDFOR3  -  SKIP  } 

bz  } 

SKIP     ldz  } 

ldl  8  ;  ldc  24=ENDFOR3-FOR3  } 

neg  } 

bz  ;  forced  jump  } 

ENDFOR3  IdO  5  ;  here  if 

not  (k<size+l)  } 

st  ;  store  it  to  get  it  off  the 

stack  } 

;  count ++  } 

IdO  4  } 

Id  } 

IdO  1  } 

add  } 

IdO  4  } 

st  } 

;  i++  ) 

INC     IdO  1  } 

Id  } 

IdO  1  } 

add  } 

dupe  } 

IdO  1  } 

st  } 

ldl  5;  ldc  21=size+l  } 

equal  ) 

ldc  93=$5d  ;ENDFOR2  -  FOR2  } 

neg  } 

bz;  goto  beginning  of  for  loop  } 

ENDFOR2  nop  } 
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Appendix  E 
Pascal  Code  for  Example  Specification 


program  simulator (input,  output); 

{#  Itty  Bitty  Stack  Machine  Simulator  Specification} 
var  ljbrom,  ljbexit,  ljbrelpc,  ljboffset,  Ijbnewpc,  ljbpsp, 
ljbpushpop,  ljbselfp,  ljbafp,  ljbaddr,  1 jbneg,  - 1 jbparm, 
ljbop,  ljbselr,  ljbalu,  ljbnewst,  ljbwrite,  tempstate, 
adrstate,  datastate,  opnstate,  temppc,  adrpc,  datapc, 
opnpc,  tempsp,  adrsp,  datasp,  opnsp,  tempfp,  adrfp, 
datafp,  opnfp,  templeft,  adrleft,  dataleft,  opnleft, 
tempright,  adrright,  dataright,  opnright,  tempir,  adrir, 
datair,  opnir,  tempdata,   adrdata,  datadata,  opndata, 
tempram,  adrram,  dataram,  opnram,   tempprog,  adrprog, 
dataprog,  opnprog:  integer; 
cycles,  cyclecount :  integer; 
ljbstate:  array[0..0]  of  integer; 
ljbpc:  array[0..0]  of  integer; 
ljbsp:  array[0..0]  of  integer; 
ljbfp:  array[0..0]  of  integer; 
ljbleft:  array [0..0]  of  integer; 
ljbright:  array[0..0]  of  integer; 
ljbir:  array[0..0]  of  integer; 
ljbdata:  array[0..0]  of  integer; 
ljbram:  array [0 .. 4095]  of  integer; 
ljbprog:  array [0 .. 132]  of  integer; 

function  land  (a,  b:  integer):  integer; 
type  bitnos  ■  0..31; 

bigset  =  set  of  bitnos; 
var  intset:  record  case  boolean  of 

false:  (i,  j:  integer); 
true:   (x,  y:  bigset) 
end; 
begin 

with  intset  do  begin 
i  :=  a; 
j  :=  b; 
x  :  =  x  *  y ; 
land  :=  i 
end 
end  {land}; 
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procedure  initvalues; 

var  i:  integer; 

begin 

for  i  :=  0  to  0  do 

ljbstate[i]  :=  0; 

terapstate  :=  0; 
for  i  :=  0  to  0  do 

ljbpc[i]  :=  0; 

terappc    :=   0; 
for   i    :=   0   to   0   do 

ljbsp[i]     :=   0; 

tempsp    :=   0; 
for    i    :=    0    to    0    do 

ljbfp[i]     :=   0; 

tempfp  :=  0; 
for  i  :=  0  to  0  do 

ljbleft [i]  :=  0; 

temple ft  :=  0; 
for  i  :=  0  to  0  do 

ljbright[i]  :=  0; 

tempright  :=  0; 
for  i  :=  0  to  0  do 

ljbir[i]  :=  0; 

tempir  :=  0; 
for  i  :=  0  to  0  do 

ljbdata[i]  :=  0; 

tempdata  : =  0 ; 
for  i  :=  0  to  4095  do 


ljbrara[i]     := 

0; 

tempram    :=   0 

; 

ljbprog[0]     : 

=   0; 

ljbprog[l]     : 

=   0; 

ljbprog[2]     : 

=   3; 

ljbprog[3]     : 

=   10; 

ljbprog[4]     : 

=   0; 

ljbprog[5]     : 

=    4; 

ljbprog[6]     : 

=  l; 

ljbprog[7]     : 

=    2; 

ljbprog[8]     : 

=   4; 

ljbprog[9]     : 

=   13 

ljbprog[10] 

:=    2 

1 jbprog  [11] 

:=    5 

ljbprog[12] 

:=    2 

1 jbprog  [13] 

:=    1 

ljbprog[14] 

:=    10; 

1 jbprog  [15] 

:=    4 

1 jbprog [16] 

:=   2 

1 jbprog[17] 

:=    1 

ljbprog[18] 

:=    0 

ljbprog[19] 

:=   2 

ljbprog[20] 

:=    1 

3; 
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1 jbprog 

21] 

= 

4 

1 jbprog 

22] 

= 

3; 

1 jbprog 

23] 

= 

10; 

ljbprog 

24] 

■ 

7 

1  jbprog 

25] 

= 

3 

ljbprog 

26] 

- 

1 

ljbprog 

27] 

= 

9 

ljbprog 

28] 

- 

14; 

ljbprog 

29] 

= 

2; 

ljbprog 

30] 

= 

5; 

ljbprog 

31] 

= 

13; 

ljbprog 

32] 

= 

1 

ljbprog 

33] 

= 

2 

ljbprog 

34] 

- 

1 

ljbprog 

35] 

- 

13; 

ljbprog 

36] 

= 

2; 

ljbprog 

37] 

= 

1; 

ljbprog 

38] 

= 

12; 

ljbprog 

39] 

= 

2; 

ljbprog 

40] 

= 

6; 

ljbprog 

41] 

= 

10; 

ljbprog 

42] 

■ 

12; 

ljbprog 

43] 

= 

0 

ljbprog 

44] 

= 

1 

ljbprog 

45] 

- 

0 

ljbprog 

46] 

= 

0 

ljbprog 

47] 

= 

3 

ljbprog 

48] 

= 

10; 

ljbprog 

49] 

= 

14; 

ljbprog 

50] 

= 

2; 

ljbprog 

51] 

= 

1; 

ljbprog 

52] 

= 

12; 

ljbprog 

53] 

= 

4; 

ljbprog 

54] 

= 

4; 

ljbprog 

55] 

= 

10; 

ljbprog 

56] 

« 

2; 

ljbprog 

57] 

= 

3; 

ljbprog 

58] 

= 

10; 

ljbprog 

59] 

■ 

4 

ljbprog 

[60] 

= 

0 

ljbprog 

[61] 

= 

1 

ljbprog 

[62] 

= 

1 

ljbprog 

[63] 

= 

0 

ljbprog 

64] 

= 

0 

ljbprog 

[65] 

= 

0 

ljbprog 

[66] 

= 

13; 

ljbprog 

[67] 

= 

4 

ljbprog 

[68] 

= 

2 

ljbprog 

[69] 

= 

2 

ljbprog 

[70] 

= 

13; 

ljbprog 

[71] 

= 

10; 

ljbprog 

[72] 

= 

4 
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1  jbprog 

73]  : 

=  2; 

1 jbprog 

74]  : 

=  6; 

1 jbprog 

75]  : 

-  10; 

1 jbprog 

76]  : 

=  l; 

1 jbprog 

77]  : 

=  0; 

1  jbprog 

78]  : 

=  2; 

ljbprog 

79]  : 

=  13; 

ljbprog 

80]  : 

-  2; 

ljbprog 

81]  : 

=  2; 

ljbprog 

82]  : 

=  12; 

ljbprog 

83]  : 

=  10; 

ljbprog 

84]  : 

=  4; 

ljbprog 

85]  : 

=  3; 

ljbprog 

86]  : 

=  5; 

ljbprog 

87]  : 

-  6; 

ljbprog 

88]  : 

=  2; 

ljbprog 

89]  : 

=  5; 

ljbprog 

90]   : 

-  14; 

ljbprog 

91]  : 

=  l; 

ljbprog 

92]  : 

=  3; 

ljbprog 

93]  : 

=  8; 

ljbprog 

94]  : 

=  9; 

ljbprog 

95]  : 

=  14; 

ljbprog 

96]  : 

=  2; 

ljbprog 

97]  : 

=  5; 

ljbprog 

98]  : 

=  13; 

ljbprog 

99]  : 

=  2; 

ljbprog 

100] 

:=  4; 

ljbprog 

101] 

:=  12; 

ljbprog 

102] 

:=  2; 

ljbprog 

103] 

:=  1; 

ljbprog 

[104] 

:=  10; 

ljbprog 

105] 

:=  2; 

ljbprog 

[106] 

:=  4; 

ljbprog 

[107] 

:=  13; 

ljbprog 

[108] 

:=  2; 

ljbprog 

[109] 

:=  1; 

ljbprog 

110] 

:=  12; 

ljbprog 

111] 

:=  2; 

ljbprog 

[112] 

■■=  l; 

ljbprog 

113] 

:=  10; 

ljbprog 

114] 

:=  4 

ljbprog 

[115] 

:=  2 

ljbprog 

ril6] 

:=  1 

ljbprog 

117] 

:=  13; 

ljbprog 

118] 

:=  3 

ljbprog 

119] 

:=  5 

ljbprog 

120] 

:=  7 

ljbprog 

121] 

:=  0 

ljbprog 

122] 

:=  1 

ljbprog 

123] 

:=  0 

ljbprog 

124] 

:-  0 
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ljbprog[125] 

- 

5 

ljbprog[126] 

= 

13; 

ljbprog[127] 

= 

9; 

ljbprog[128] 

= 

14; 

ljbprog[129] 

= 

0 

ljbprog[130] 

= 

0 

ljbprog[131] 

■ 

0 

ljbprog[132] 

= 

0 

tempprog  :=  0; 

end;  {initvalues} 

function  dologic (funct,  left,  right:  integer):  integer; 
const  mask  =  2147483647; 
var  value  :  integer; 
begin 

value  :=  0; 

case  funct  of 

0  :  value  :=  0; 

1  :  value  :=  right; 

2  :  value  :=  left; 

3  :  value  :=  mask  -  left; 

4  :  value  :=  left  +  right; 

5  :  value  :=  left  -  right; 

6  :  while  (right  >  0)  and  (left  <>  0)  do  begin 

left  :=  land(left  +  left,  mask); 
value  :=  left; 
right  :=  right  -  1; 
end; 

7  :  value  :=  left  *  right; 

8  :  value  :=  landdeft,  right); 

9  :  value  :=  left  +  right  -  landdeft,  right); 

10:  value  :=  left  +  right  -  landdeft,  right)  *  2; 

11:  value  :=  0; 

12:  if  left  =  right  then  value  :=  1; 

13:  if  left  <  right  then  value  :=  1 
end;  {case} 
dologic  :=  value; 
end;  {dologic} 


function  sinput (address :  integer):  integer; 
var  datum:  char; 

data:  integer; 
begin 

if  address  =  0  then  begin 
read  (input,  datum); 
sinput  :=  ord (datum) 
end 

else  if  address  =  1  then  begin 
read  (input,  data) ; 
sinput  :=  data 
end 
else  begin 
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write (output,  'Input  from  address 
readln (input,  data); 
s input  :=  data; 
end 
end;  {sinput} 


address : 1, 


procedure  soutput (address,  data:  integer); 

begin 

if  address  =  0  then  writeln (output,  chr(data)) 
else  if  address  =  1  then  writeln (output,  data) 
else  writeln (output,  'Output  to  address  ',  address :1, 
':  ',  data:l) 

end;  {soutput} 


begin 

init values; 

cycles  :=  0; 

if  cycles  =  0  then  begin 

writeln ( 'Number  of  cycles  to  trace') 

read (cycles) ; 
end; 

cyclecount  :=  0; 

while  cyclecount  <=  cycles  do  begin 
case  land(tempstate,  63)  of 


0 

ljbrom  := 

=  4184 

; 

1 

ljbrom  := 

=  256; 

2 

ljbrom  :  = 

>  256; 

3 

ljbrom  :  = 

>  256; 

4 

ljbrom  :  = 

>  288; 

5 

ljbrom  :  = 

■  256; 

6 

ljbrom  :  = 

--   256; 

7 

ljbrom  :  = 

■  256; 

8 

ljbrom  :  = 

■  296; 

9 

ljbrom  :  = 

■  256; 

10 

:  ljbrom 

-  143; 

11 

:  ljbrom 

-  1536; 

12 

:  ljbrom 

=  256; 

13 

:  ljbrom 

=  150; 

14 

:  ljbrom 

=  832  6; 

15 

:  ljbrom 

=  576 

16 

:  ljbrom 

=  256 

17 

:  ljbrom 

=  25C 

18 

:  ljbrom 

=  396 

19 

:  ljbrom 

=  16; 

20 

:  ljbrom 

=  320; 

21 

:  ljbrom 

=  2182; 

22 

:  ljbrom 

=  17  92; 

23 

:  ljbrom 

=  320; 

24 

:  ljbrom 

=  320; 

25 

:  ljbrom 

=  0; 

26 

:  ljbrom 

-  0; 

27 

:  ljbrom 

=  0; 
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28  : 

1 jbrom 

= 

0, 

29  : 

ljbrom  . 

= 

0, 

30  : 

1 jbrom  • 

= 

0, 

31  : 

ljbrom 

= 

4164; 

32  : 

ljbrom 

= 

0; 

33  : 

ljbrom 

■ 

132 

34  : 

ljbrom 

= 

196 

35  : 

ljbrom 

= 

196 

36  : 

ljbrom 

= 

132 

37  : 

ljbrom 

= 

134 

38  : 

ljbrom 

= 

134 

39  : 

ljbrom 

= 

134 

40  : 

ljbrom 

= 

256 

41  : 

ljbrom 

= 

256 

42  : 

ljbrom 

= 

134 

43  : 

ljbrom 

■ 

134 

44  : 

ljbrom 

■ 

32; 

45  : 

ljbrom 

- 

134 

46  : 

ljbrom 

= 

134 

47  : 

ljbrom 

■= 

256 

48  : 

ljbrom 

= 

0; 

49  : 

ljbrom 

= 

196 

50  : 

ljbrom 

= 

134 

51  • 

ljbrom 

» 

134 

52 

ljbrom 

= 

2437; 

53 

ljbrom 

= 

131; 

54 

ljbrom 

= 

64; 

55 

ljbrom 

= 

0 

56 

ljbrom 

= 

0 

57 

ljbrom 

= 

0 

58 

ljbrom 

= 

0 

59 

ljbrom 

= 

0 

60 

ljbrom 

— 

0 

61 

ljbrom 

= 

0 

62 

ljbrom 

= 

0 

63 

ljbrom 

= 

0 

end; 

ljbexit  :=  dol< 

sg 

ic 

(1 

in 

dologic (land (ljbrom,  256)  div  256  +  12,  tempram, 
landdjbrom,  256)  *  16); 
case  landdjbrom,  1024)  div  1024  of 

0  :  ljbrelpc  :=  temppc; 

1  :  ljbrelpc  :=  0; 
end; 

case   landdjbrom,    512)    div   512    of 

0  :    ljboffset    :=   1; 

1  :  ljboffset  :=  templeft; 
end; 

ljbnewpc  :=  ljbrelpc  +  ljboffset; 
case  landdjbrom,  7)  of 


0 

1 jbpsp 

:=  0 

1 

1 jbpsp 

:=  0 

2 

ljbpsp 

:=  0 

E7 


=  tempfp; 
=  1; 

=  templeft; 

=  1; 

=  tempright; 

dologic  (land(ljbrom,  2)  div  2  +  land (ljbrom, 


3  :  ljbpsp 

4  :  ljbpsp 

5  :  ljbpsp 

6  :  ljbpsp 

7  :  ljbpsp 
end; 
ljbpushpop  !■ 

4),  tempsp,  ljbpsp) 
case  land(tempir,  1)  of 

0  :  ljbselfp  :=  tempsp; 

1  :  ljbselfp  :=  tempram; 
end; 

ljbafp  :=  tempfp  +  templeft; 
case  landdjbrom,  32)  div  32  of 

0  :  ljbaddr  :=  tempsp; 

1  :  ljbaddr  :=  ljbafp; 
end; 

ljbneg  :=  0  -  tempram; 
case  land (tempstate,  63)  of 


0  : 

ljbparm  :  = 

"  0; 

1  : 

ljbparm  :  = 

=  0; 

2  : 

ljbparm  :  = 

■  387; 

3  : 

ljbparm  :  = 

■  160; 

4  : 

ljbparm  :  = 

■  25; 

5  : 

ljbparm  :  = 

■  0; 

6  : 

ljbparm  :  = 

■  224; 

7  : 

ljbparm  :  = 

■  6; 

8  : 

ljbparm  :  = 

■  9; 

9  : 

ljbparm  :  = 

>  192; 

10 

:  ljbparm 

=  11; 

11 

:  ljbparm 

=  0; 

12 

:  ljbparm 

=  0; 

13 

:  ljbparm 

=  4; 

14 

:  ljbparm 

=  15; 

15 

:  ljbparm 

=  25; 

16 

:  ljbparm 

=  416; 

17 

:  ljbparm 

=  432; 

18 

:  ljbparm 

=  9; 

19 

:  ljbparm 

=  8; 

20 

:  ljbparm 

=  433; 

21 

:  ljbparm 

=  10; 

22 

:  ljbparm 

=  96; 

23 

:  ljbparm 

=  436; 

24 

:  ljbparm 

=  407; 

25 

:  ljbparm 

=  0; 

26 

:  ljbparm 

=  18; 

27 

:  ljbparm 

=  14; 

28 

:  ljbparm 

=  13; 

29 

:  ljbparm 

=  7; 

30 

:  ljbparm 

-  5; 

31 

:  ljbparm 

=  0; 

32 

:  ljbparm 

=  31; 

BS 


33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 
56 
57 
58 
59 
60 
61 
62 
63 

end; 

case 
0 
1 
2 
3 
4 
5 
6 
7 
8 
9 

10 
11 
12 
13 
14 
15 

end; 

case 
0 


1 jbparm 
1 jbparra 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 
1 jbparm 


=  1 
=  2 
=  2 
=  12 
=  30 
=  29 
=  29 
=  0; 
=  224 
=  30 
=  30 
=  12 
-  28 
=  27 
=  32 
=  0; 
=  24 
=  26 
=  19 
=  64 
=  21 
=  22 
=  0 
=  0 
=  0 
=  0 
=  0 
=  0 
=  0 
=  0 
=  0 


land(tempir,  15)  of 


1  jbop 
1  jbop 
1  jbop 
1  jbop 
1  jbop 
1  jbop 
1  jbop 
1  jbop 
1  jbop 
1  jbop 
1  jbop 
1  jbop 
1  jbop 
1  jbop 
1  jbop 
1  jbop 


0 
=  0 

=  1 

=  4 

=  1 


=  13; 

=  12; 
-  3; 
=  0; 

=  4; 

=  7; 

=  2; 

=  1; 

=  12; 

=  5; 


land (1 jbparm,  32)  div  32  of 
ljbselr  :=  tempright; 
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ljbselr  :=  tempfp; 


1 
end; 

ljbalu  :=  dologic (1 jbop,  tempram,  ljbselr); 
case  landdjbexit,  1)  +  land(ljbrom,  12288)  div  2048  of 

0  :  ljbnewst  :=  land(ljbparm,  31); 

1  :  ljbnewst  :=  land(ljbparm,  31); 

2  :  ljbnewst  :=  land (tempprog,  15)  +  land(ljbrom,  4)  * 
32; 

land (tempprog,  15)  +  land(ljbrom,  4)  * 


4 
5 

6 
7 

end; 


ljbnewst 

32; 
ljbnewst 
ljbnewst 
ljbnewst 
ljbnewst 

32; 


=   0; 

=   land (ljbparm,    31); 

=   0; 

=   land  (tempprog,    15)    +   landdjbrom,    4) 


4  + 


4  + 


case  landdjbparm,  224)  div  32  of 


1 jbwrite 
1 jbwrite 
1 jbwrite 
ljbwrite 
1 jbwrite 
ljbwrite 

16; 

ljbwrite  :=  templeft; 
ljbwrite  :=  ljbneg; 


ljbalu; 
=  ljbalu; 
=  tempfp; 
=  temppc; 

=  landftempir,  1)  ; 
=  land  (tempdata,  15)  +  land (tempram,  4095)  * 


0 
1 
2 
3 
4 
5 

6 

7 
end; 

write ('Cycle  ',  cyclecount :3) ; 
writeln; 
adrstate  :=  0; 
datastate  :=  tempstate; 
opnstate  :=  1; 
adrpc  :=  0; 
datapc  :=  temppc; 

opnpc  :=  landdjbrom,  64)  div  64; 
adrsp  :=  0; 
datasp  :=  tempsp; 

opnsp  :=  landdjbrom,  128)  div  128; 
adrfp  :=  0; 
datafp  :=  tempfp; 

opnfp  :=  land(ljbrom,  2048)  div  2048; 
adrleft  :=  0; 
dataleft 


:=  templeft; 
opnleft  :=  landdjbrom, 
adrright  : 
dataright 
opnright  : 
adrir  :=  0; 
datair  :=  tempir; 

opnir  :=  land(ljbrom,  40  96)  div  4096; 
adrdata  :=  0; 
datadata  :=  tempdata; 


3)  div 
=  0; 
:=  tempright; 

landdjbrom,  16)  div  16; 
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opndata  :=  land(l jbparm,  256)  div  256; 

adrram  :=  land  (ljbaddr,  4095); 

dataram  :=  tempram; 

opnrara  :=  land (ljbrom,  256)  div  256  +  landd jbaddr,  4096) 

div  2048; 
adrprog  :=  temppc; 
dataprog  :=  tempprog; 
opnprog  :=  0; 
tempstate  :=  ljbnewst; 
ljbstate  [adrstate]  :=  tempstate; 
case  land(opnpc,  3)  of 

0:  temppc  :=  ljbpc [adrpc] ; 
1 :  begin 

temppc  :=  ljbnewpc; 
ljbpc [adrpc]  :=  temppc; 
end; 
2:  temppc  :=  sinput (adrpc) ; 
3 :  begin 

temppc  :=  ljbnewpc; 
soutput (adrpc,  temppc) ; 
end 
end;  (case) 
case  land(opnsp,  3)  of 

0:  tempsp  :=  ljbsp [adrsp] ; 
1 :  begin 

tempsp  :«■  ljbpushpop; 
ljbsp [adrsp]  :=  tempsp; 
end; 
2:  tempsp  :=  sinput  (adrsp) ; 
3  :  begin 

tempsp  :=  ljbpushpop; 
soutput (adrsp,  tempsp) ; 
end 
end;  (case) 
case  land(opnfp,  3)  of 

0:  tempfp  :=  1 jbfp  [adrfp] ; 
1:  begin 

tempfp  :=  ljbselfp; 
1 jbfp [adrfp]  :=  tempfp; 
end; 
2:  tempfp  :=  sinput  (adrfp) ; 
3  :  begin 

tempfp  :=  ljbselfp; 
soutput (adrfp,  tempfp) ; 
end 
end;  (case) 
case  land (opnleft,  3)  of 

0:  templeft  :=  1 jbleft [adrleft] ; 
1 :  begin 

templeft  :=  tempram; 
1 jbleft [adrleft]  :=  templeft; 
end; 
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2:  templeft  :=  sinput (adrleft) ; 
3:  begin 

templeft  :=  tempram; 
soutput  (adrleft,  templeft); 
end 
end;  (case) 
case  land  (opnright,  3)  of 

0:  tempright  :=  1 jbright [adrright ] ; 
1:  begin 

tempright  :=  tempram; 
1 jbright [adrright]  :=  tempright; 
end; 
2:  tempright  :=  sinput (adrright) ; 
3:  begin 

tempright  :=  tempram; 
soutput (adrright,  tempright); 
end 
end;  (case) 
case  land(opnir,  3)  of 

0:  tempir  :=  1 jbir  [adrir] ; 
1 :  begin 

tempir  :=  tempprog; 
ljbir [adrir]  :=  tempir; 
end; 
2:  tempir  :=  sinput (adrir) ; 
3 :  begin 

tempir  :=  tempprog; 
soutput (adrir,  tempir) ; 
end 
end;  (case) 
case  land(opndata,  3)  of 

0:  tempdata  :=  ljbdata [adrdata] ; 
1 :  begin 

tempdata  :=  tempprog; 
ljbdata [adrdata]  :=  tempdata; 
end; 
2:  tempdata  :=  sinput  (adrdata) ; 
3 :  begin 

tempdata  :=  tempprog; 
soutput (adrdata,  tempdata) ; 
end 
end;  (case} 
case  land(opnram,  3)  of 

0:  tempram  :=  1 jbram[adrram] ; 
1:  begin 

tempram  :=  ljbwrite; 
1 jbram[adrram]  :=  tempram; 
end; 
2:  tempram  :=  sinput (adrram) ; 
3 :  begin 

tempram  :=  ljbwrite; 
soutput (adrram,  tempram) ; 
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end 
end;  {case) 

tempprog  :=  ljbprog [adrprog] ; 
cyclecount  :=  cyclecount  +  1; 
if  cyclecount  =  cycles  +  1  then  begin 

writeln ( 'Continue  to  cycle  (0  to  quit)'); 

read (cycles) ; 
end; 

end;  {while} 
end. 
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Appendix  F 
Example  of  specification  translation  to  a  hardware  diagram 


Specification  in  ASIM  II 


#   tiny  computer  specification  1986  June  12 

{macro  definition  of  instrucions} 

~LD  256   ~ST  384   ~BB  512   ~BR  640   ~SU  768 

state*  nextstate  phase  pc*  incpc  newpc  ir  decode  ma 
memory  ac*  borrow  alu  sel  sell  b2  sub. 

M  state  0  nextstate. 0.1  1  1  {state  counter} 

A  nextstate  %0100  state  1 

S  phase  state. 0.1  %0001  %0010  %0100  %1000 

A  incpc  %0100  pc  1  {add  pc+1  (or  load  ir)  in 

phase .2 } 
S  newpc  decode . 1  incpc  ir 
M  pc  0  newpc. 0.6  phase. 2  1 
M  ir  0  memory  phase . 1  1 
S  decode  ir . 7 . 9 

0 

0 

phase. 3, #00 

phase. 2 

borrow, #0 

#10  {unconditional  only} 

1, phase. 3, #00 

0 
A  alu  decode. 3, #01  ac  memory. 0.9   {subtract  or  load} 
M  ac  0  alu. 0.10  decode. 2  1 

M  borrow  0  sel  b2  1      {borrow  flag  set  only  on 

subtract} 

Fl 


A  b2  8  phase. 3  sub 
A  sub  12  %110  ir.7.9 
A  sel  8  sub  sell 


A  sell  8  alu.10  phase. 3 

S  ma  phase. 2  pc  ir 

M  memory  ma. 0.6  ac  decode . 0  -128 

{decimal  memory  data  follows 


{operation  and  during  phase  3} 
{is  this  a  subtract  operation?} 
{  select  based  on  subtract 
operation  and} 

{phase  3  and  bit  10  of  alu} 


-LD+30 
-SU+31 

-LD+30 

-SU+32 

-LD+32 

-SU+30 

-LD+34 

-SU+33 

-LD+30 

-SU+31 

0  0  0 

0  0  0 

5  7  7 


{load  accumulator  from  location  30} 
{subtract  value  in  location  31  from 
accumulator} 


0000000000000 

0 

10  5 


0  0  0  0  0 


0  0  0  0  0  0 
0  0  0  0  0  0 


0  0  0  0  0  0  0 

0000000000 

0000000000 


00000000000000 
00000000000000 


0  0 
0  0 


0000000000000000 
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2K  x  8  bit  RAM 

quad  AND 

dual  D  flip  flop 

4  bit  adder 

4  bit  comparator 

"  to  1  multiplexor 

dual  4  to  1  multiplexor 

quad  2  to  1  multiplexor 

hex  D  flip  flop 

quad  D  flip  flop 

4  bit  alu 
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ABSTRACT 

ASIM  II  (Architecture  Simulator  II)  is  a  compiler  which  compiles 
an  electronic  hardware  description  to  Pascal.  When  executed,  this  Pascal 
code  simulates  the  hardware  described  in  the  specification.  The 
components  of  an  electronic  system  are  described  by  three  primitives: 
ALU,  selector,  and  memory.  These  three  primitives  are  sufficient  to 
describe  any  piece  of  digital  electronic  equipment  and  resemble  their 
hardware  counterparts  in  a  digital  electronic  system.  ASIM  II  is  different 
from'  other  computer  hardware  description  languages  in  that  it  uses  only 
these  three  primitives.  It  is  not  based  upon  an  underlying  programming 
language  on  which  it  is  implemented,  or  on  a  more  complex  set  of 
primitives.  ASIM  II  significantly  reduces  the  simulation  time  over  an 
interpreter  while  maintaining  the  same  functionality. 


